[cabfpub] Certificate lifetimes: end state or trajectory?

[Geoff Keating]

> On 3 Mar 2017, at 3:27 pm, Peter Bowen via Public <public at cabforum.org> wrote:
> 
> I think that “algorithm” should be taken in a broader context that just cryptographic algorithm.  For example, when looking at the validation method that allows domain validation via a change on a website, we found several issues:
> 
> - A number of websites will echo back the URI path in the response body (https://cabforum.org/pipermail/public/2016-April/007504.html) and will return HTTP 200 for any path.  This means a validation process that is “ensure that GET /<long random value>.txt returns 200” or “GET /<long random value>.txt returns <long random value>” is vulnerable
> - A number of websites allow users to create content (e.g forums).  This means any validation process that is “here is <long random value>.  Put it on your web server and give us the path to it” is vulnerable
> 
> The changes in ballot 169 attempt to mitigate these risks, but there are lots of existing certs out there that passed validation using some variant of one of these methods.  One option is to just require CAs revoke all existing certificates that were issued using website control validation, but this would be highly impactful to customers.  The other option is to cease using the vulnerable method and let the existing certs expire.  In this case the maximum validity period defines how long potentially mis-issued certificates are live.
> 
> Assuming we agree on the principle of least surprise, revocation is a far worse choice than leaving the certificate live until expiration.  However we still want bound how long this transition period will last. In most cases, the validity period of certificates is the largest driver of the duration of the transition period; by shortening it we shorten there transition period.  So I disagree with your premise; there is a security benefit to shorter certificates, just like there is a security benefit to more frequent software updates.

I thought this was interesting in the context of automatically updating certificates.  Imagine the scenario where most certificates are 90-day, automatically requested and validated, using a method like the broken one above.  We find the problem described above and want to make a change.  So, give a 6 month implementation period for CAs, and 9 months later all unexpired certificates have been issued with the new method, right?  No!  Now not only must CAs make a change, but millions of devices must make a change, which puts the provided token in a different place in their web site.  Some will take years to have the change deployed.  Some custom systems will need to do it as part of a regular release cycle, and might want engineering resources scheduled a year in advance.  Some abandoned devices might never make the change and need to be upgraded by replacement, or need a manual exception method.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3321 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170306/812e05ab/attachment.p7s>