Evaluate CRLite for certs older than $merge_delay
Categories
(Core :: Security: PSM, enhancement, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox83 | --- | fixed |
People
(Reporter: jcj, Assigned: keeler)
References
(Blocks 1 open bug)
Details
(Whiteboard: [psm-assigned])
Attachments
(1 file)
On new certificates, even if a filter is newer than the oldest timestamp of the certificate (Bug 1605273), the certificate may not be in the filter until we've reached the Maximum Merge Delay for the logs in which the certificate was logged.
We don't track timestamps that closely in this version of CRLite, so we should choose a conservative value to apply to the if cert newer than filter conditional to encompass the worst MMDs plus slush. We should also ensure that when we fail that conditional, we emit telemetry that the cert was too new. (Already exists, just ensure the branch gets taken).
Per OOB conversation, we should make this a pref if possible, perhaps starting at 3 days and we can evaluate making it 2 days. The maximum allowed MMD is 1 day (24 hours), so any value greater than that should, by other root stores' policies, include all certificates.
|
Assignee | |
Comment 1•4 years ago
|
||
This patch adds the preference "security.pki.crlite_ct_merge_delay_seconds"
that adds a configurable delay between the earliest certificate timestamp and
the filter creation date. This allows the implementation to take into account
CT log merge delays (i.e. when an SCT exists for a certificate but that
certificate hasn't yet been merged into the log).
The default value is 28 hours in seconds. The minimum value is 0 seconds, and
the maximum value is one year in seconds.
|
||
Updated•4 years ago
|
|
|
Assignee | |
Updated•4 years ago
|
|
|
Assignee | |
Updated•4 years ago
|
Pushed by dkeeler@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/6432addb0df4 CRLite: allow taking the log merge delay into account r=jcj
|
||
Comment 3•4 years ago
|
||
| bugherder | ||
Description
•