[cabfpub] Certificate lifetimes: end state or trajectory?

Peter Bowen pzb at amzn.com
Fri Mar 3 23:27:25 UTC 2017


> On Mar 3, 2017, at 9:54 AM, Phillip Hallam-Baker via Public <public at cabforum.org> wrote:
> 
> From: Gervase Markham [mailto:gerv at mozilla.org]
> 
>> On 03/03/17 17:25, Phillip Hallam-Baker wrote:
>>> But when we get into discussions, the security reason for doing it is
>>> so that 'bad certs' are valid for shorter times. Whether you like it
>>> or not, that is a validity argument by definition.
>> 
>> But it's not a problem that can be solved by revocation. Well, technically you
>> could solve the problem that e.g. "we've issued 2 million 39-month certs
>> using an algorithm we now known to be broken" by revoking them all, but in
>> practice the level of disruption is too great.
>> However, making the max validity period 13 months means that people will
>> be planning to rotate their certs on a yearly basis anyway.
> 
> And it isn't a problem that can be solved by shortening the certificate lifetime either.
> 
> We are dealing with a complex infrastructure in which it currently takes about ten years to deploy a new algorithm.


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 <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.

Thanks,
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170303/59861d4d/attachment-0003.html>


More information about the Public mailing list