#6 Certificate Transparency Log Certificate Acceptance Proposal

[Anonymous]

Originally created by: taknira

Problems:

• Log Size: Currently, bringing up new logs does not help with size issues, as if the new logs have the same root set at the old logs, they could be filled with all of the same certificates, resulting in a duplicate logs, and not solving the problem of log size in any way.
• Log lifetime management: Logs are getting filled with short lived certs (ahem, Let’s Encrypt :P) but then having to be kept alive for years after most of the certificates they contain expire due to the small number of long lived certs in them.

Idea:

When a log operator brings up a new Log, they specify:

• A list of accepted roots (as usual)
• (optionally) A time range: Start, End

For a certificate to be accepted by the Log:

• The certificate must be ‘valid’ X509 (as usual)
• The certificate must chain to an accepted roots (as usual)
• If a time range was specified:
  • The certificate’s ‘Not After’ validity field value must:
  • Be at or after ‘Start’
  • Be before ‘End’

How could Log Operators use this:

Suppose the longest lived cert that a CA can/will ever issue is 3 years (I'm not sure what it actually is, so this example would need to be adjusted to accommodate whatever it really is).

Using this new idea, a log operator could then create 4 logs (to cover a rolling 3 year period), each with the same set of accepted roots, but with (Start, End) values of:
(initial, initial+1yr)
(initial+1yr, initial+2yrs)
(initial+2yrs, initial+3yrs)
(initial+3yrs, initial+4yrs)
where initial = ~when the logs are created

New certificates issued with short lifetimes (for example Let’s Encrypt certs) would initially end up in the (initial, initial+1yr) log, whereas new certificates with longer lifetimes would end up in the logs with later acceptance ranges. Existing certificates that have not yet expired would fit into whichever log accepts their ‘Not After’ value, and expired certificates would be submitted to already existing archival logs (e.g. Google Daedalus).

As now progressed, and neared initial+1yr, another log would be spun up with (Start, End) = (initial+4yrs, initial+5yrs), to continue to cover any new certificates created with a 3 year lifetime. New short lived certificates would start being logged in the (initial+1yr, initial+2yrs) Log.

Once now passed initial+1yr, the log with (Start, End) = (initial, initial+1yr) would become archival, and not require the same level of maintenance, as all of the certificates within it would be expired.

Pros:

• Hard date at which the log is no longer active - very clear log lifetime.
• Logs sizes are limited to however many certs expire during the specified range.
• Adds an element of predictability to when certain new Logs will be introduced. Can plan spinning up Logs in advance.

Cons:

• Adds complexity to the ecosystem:
  • CAs either have to know which Log to submit to/which log will accept the expiry dates of its certs, or submit to all Logs with the understanding that only some will return an SCT.
  • CAs have to change which Logs they submit to as time rolls on.
• Shipping with a ‘baked in’ list of Logs that all specify the optional Start, End values means that, after the latest End value, and without any update mechanism. CT will no longer work for that product.

[Anonymous]

Originally posted by: pphaneuf

Backlink to the ct-policy mailing list topic: https://groups.google.com/a/chromium.org/d/topic/ct-policy/bArUq2nU41E/discussion