[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes

[Geoff Keating]

> On 16 Aug 2019, at 11:26 pm, Ryan Sleevi via Servercert-wg <servercert-wg at cabforum.org> wrote:
> 
>  * CRLs and OCSP have long been shown to be non-viable at Internet-scale, in terms of how they externalize costs like privacy, performance, and stability to Subscribers and Relying Parties. While alternative, browser-specific methods also exist, they also allow CAs to externalize the cost of their practices onto users and browsers, growing as the number of unexpired certificates grow.  Reducing certificate lifetimes meaningfully protects users, regardless of the revocation method used, and helps reduce the overall costs paid by users.

I thought it might be worth explaining how the costs come out in Apple’s deployed (and, I think, successful) revocation system.

In general, the costs in Apple’s system are proportional to the rate of new revocations.  The total number of (unexpired) revoked certificates at any given moment is much less important, as is the total number of issued certificates.

A change in certificate lifespan:
- Will probably not reduce the number of revocations—a certificate which would have been revoked after say 20 months will instead be renewed after 12 months and the new certificate will be revoked after 8 months.
- Is more likely to increase the number of revocations, because a significant number of revocations appear to be related to issuance, and since there will be twice as much issuance (for certificates affected by the change), it would be expected that there will more of those revocations.
- Will reduce the number of unexpired revoked certificates, because revoked certificates will expire faster.
- Will increase the total number of issued certificates; there will be more expired certificates, of course, but also there will be more unexpired certificates because of overlap between issuance of a new certificate and expiry of the old one.

Overall I expect that reducing certificate lifespans will slightly increase costs, primarily because of the second item.

>   * Existing certificate validity periods create risk for Relying Parties wishing to enforce the Baseline Requirements or Root Program requirements, by allowing CAs to “backdate” certificates in order to attempt to bypass date-based program requirements. Reducing certificate lifetimes reduces the window of exposure to such bypasses. As this has happened multiple times, by past and present members of the CA/Browser Forum, reducing certificate lifetimes represents the safest way to detect and counter this risk.

In Apple’s system this is or will be unnecessary.  Once legacy 5-year certificates expire (in 2021, I think) it will be the case that even under current lifespan rules, for Apple all root program TLS certificates will be required to be CT qualified, and so it will not be possible to backdate certificates—to be precise, a CA can (as today) set whatever notBefore date it wants, but the CT entry will show the actual date of issuance.  Further changes to lifespan rules won’t affect this.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3429 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190820/90b91dba/attachment.p7s>