[cabfpub] SHA-1 changes and certificate lifetimes

[Geoff Keating]

On 13 Nov 2013, at 11:30 am, Wayne Thayer <wthayer at godaddy.com> wrote:

> Hi Gerv,
> 
> On 13/11/13 10:59, Gervase Markham wrote:
>>> I'm a bit surprised by this and don't see the relationship between 
>>> this proposal and the new SHA-2 requirements. It is a fact that most 
>>> all certs will have to be replaced in the next 3 years, but why does 
>>> that imply that they need to be replaced with stronger certs that also 
>>> expire in no more than 3 years?
>> 
>> It is already the CAB Forum's stated intention to move the maximum issuance lifetime to 39 months. However, due to (if I remember
>> correctly) concerns about outstanding legacy certs, and that some CAs might be unduly penalised as they were greater users of longer-life certs than others, it was not thought possible to make >such a change immediately. So, some time ago, we set the date as April 2015.
>> 
>> Now, however, there is no unlevel playing field or outstanding long-lived legacy base because all (or almost all) existing certs now have an effective lifetime of just over 3 years. So it seems a good >opportunity to move the already-agreed deadline to match the /de facto/ deadline.
> 
> There will still be the same "long-lived legacy base" of certificates until they are replaced with SHA-2 sometime between now and Jan 1, 2017.  This proposal doesn't force these to be replaced with shorter duration certificates.
> 
> I still don't understand how this proposal is connected to the new SHA-2 rules.  Maybe the concern is that CAs will "upsell" customers to a new cert when replacing their existing SHA-1 certs, thus inflating the number of 4 & 5 year certs issued over the next year?

Part of the motivation for the original lax deadline was that it didn't really help to immediately shorten the duration to 3 years, because there were certificates that were already existing and had a 10-year duration, so it would take 7 years to get to the point where all certificates had a 3 year remaining duration.  However all or almost all of those (I'll check and see if I can find a single SHA-2 cert with an expiry past 2018) will need to be revoked by 2017.

So the result is:

10-year cert issued on the BR effective date: would have expired July 2022, but now disallowed starting January 2017
5-year SHA-2 cert issued today: expires February 2019   [note it's really 5 years + 3 months]
5-year SHA-2 cert issued April 2015: expires July 2020
3-year SHA-2 cert issued April 2015: expires July 2018

So, at the moment, we won't be able to get to the point where all certificates have a 3 year or less remaining duration until April 2017, but those certificates haven't been issued yet, so if we bring the 3-year transition date forward then we can shorten this time.  I'd suggest April 2014, though, not 'immediate', to give CAs time to adjust; that would mean all certificates have a 3 year or less remaining duration in April 2016.

> In addition, reducing the allowed lifetime actually makes it harder
> to transition longer duration certs to SHA-2.  If a CA issues a 5
> year SHA-1 cert today and then can't reissue it with SHA-2 for the
> full term starting on Jan 1, then perhaps the least bad choice is to
> wait until the remaining lifetime of the cert is less than 39
> months.


This problem will occur with pre-BR 10-year certs anyway, some of those can't be reissued for their original term at any time before they stop working.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4103 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20131113/97abe3f1/attachment.bin