Limit CanSignHttpExchange certificate lifetimes

[jyasskin]

In the blink-dev Intent-to-Ship thread, @AGWA suggests

It may also be a good idea to limit the lifetime of certificates used in SXG, to reduce the amount of time that an illegitimate certificate can be used, in case an attacker exploits a CA vulnerability to obtain future-dated good OCSP responses.

• @AGWA suggests 7-14 days.
• @clintwilson says "Something around 7-10 days would be a nice target IMO, but even restricting to 30-90 days would be a substantial improvement."
• If we go to 7 days, we can probably get rid of any mention of OCSP responses. What's the longest certificate lifetime where folks would be comfortable dropping our requirement for OCSP stapling?
• A very-short lifetime will be a problem if a CA has to temporarily disable issuance, for example after security weaknesses in certain domain validation methods are discovered.
• Even a 90-day limit probably requires automated certificate rotation, a'la ACME. Shorter certainly does.
• Should we say anything about re-using an old public key in a new certificate?

These requirements may well wind up in the BRs instead of this repository's specs, but this issue will track getting them where they need to go.

[jyasskin]

We talked to @grittygrease from Cloudflare about shorter lifetimes. My (fallible) notes are:

• 90-day lifetimes seem ok; anything shorter would require some code changes.
• 7-day lifetimes would multiply the number of certificates they need to handle enough that current designs might not scale.
• 7-day lifetime would limit uptime. In practice they see longer downtime periods for certificate issuance than OCSP.
• Clock skew is an issue, but SXG's requirement for stapled OCSP responses hits those issues anyway.
• Reusing key material across successive certificates doesn't help with any of the important problems.
• 7-day certificates could make CT logs significantly bigger, which could hurt that ecosystem.
• Future-dated OCSP responses seem like they should be forbidden by BR 4.9.9 ("OCSP responses MUST conform to RFC6960 and/or RFC5019.") and those RFCs saying "The time at which the status was known to be correct SHALL be reflected in the thisUpdate field of the response." and "When pre-producing OCSPResponse messages, the responder MUST set the thisUpdate, nextUpdate, and producedAt times as follows: thisUpdate: The time at which the status being indicated is known to be correct.", respectively. Thus, not too excited about shortening lifetimes past 90 days.

[jyasskin]

@clintwilson asked in #383 that we have "some very rough consensus on max validity" before we codify a particular limit.

• Given Cloudflare's points, it seems like 7-day validities definitely won't work with the current state of the ecosystem.
• 14-day probably has similar problems.
• Anything longer than that still needs stapled OCSP responses, so doesn't help us simplify the format or parsing.
• @sleevi mentioned somewhere that a 30-day max-validity was about the longest that would help mitigate future-dated OCSP responses (for CAs that don't believe they're already forbidden by the BRs).
• A 60- or 90-day maximum still has the following benefits:
  • Improves ecosystem agility by setting the upper-bound on how long it takes to roll out changes to certificate-related things.
  • Bounds validation risks: if a validation method (e.g. BR 3.2.2.4.1) or process (e.g. lack of a CAA record) isn't secure enough, then the lifetime is the upper-bound for the 'not secure' certificates, which could let us leave SXGs up while those certs expire.
  • Bounds the length of time an undetected compromised key can be used.
• @shigeki for Yahoo! Japan is worried about the viability of even a 90-day limit for their processes and the certificate reseller they use.

The max-validity is not intended to handle CA compromise like DigiNotar as suggested in #383 (comment), since for that browsers would revoke the affected root.

So, let's see if we can find rough agreement on a max-validity that we expect to hold until at least January 2020. This could change early if a significant issue comes up or if Mozilla or Safari demand a particular max-validity in order to support the specification, but we won't expect to change it early.

I'd like to pick 90 days because LetsEncrypt has shown it can work for lots of server operators, and I don't know of a similar proof of concept for shorter validity periods.

I'm going to run a poll by posting 30-, 60-, and 90-day limits as Github comments. Use the 👍 reaction on an option if you're pretty sure it'll work for the ecosystem, and 👎 if you're pretty sure it won't, and feel free to write a longer answer as a comment. Thanks!

[jyasskin]

Bound the maximum Validity Period at 30 days.

[jyasskin]

Bound the maximum Validity Period at 60 days.

[jyasskin]

Bound the maximum Validity Period at 90 days.

[jyasskin]

I don't see any objections to 90 days, so I'll merge that as the limit, and will resist calls to change it again until next year.

[jyasskin]

Fixed by #383, although folks should feel free to re-open this question in 2020.