[cabfpub] SHA-1 changes and certificate lifetimes

[Wayne Thayer]

On 13/11/13 10:26, Gervase Markham wrote:
>Now that Microsoft have made their announcement about SHA-1[0], I would like to discuss and then ballot a change to reduce the maximum certificate lifetime in the BRs to 3 years sooner than >originally planned. (This is BR section 9.4.) This is something that we have been wanting to do and have agreed to do, but legacy concerns meant that the transition date to 3 year issuance was >originally set for April 1st 2015.
>
>However, due to the SHA-1 announcement, more than 98% of certificates[1] used on the public Internet are going to have to be replaced within just over 3 years anyway. (Assuming that "works in >Windows" is a requirement that everyone has for their secure website.) So now seems like a very good time to move the date, without some CAs who do more long-life issuance feeling they are >being unfairly penalised.

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?

As of Jan 2, 2014, CA's will need to stop using SHA-1 for certs with durations greater than 2 years in order to meet the Jan 1, 2017 SHA-2 deadline in Windows.  That means we'll need to require SHA-2 on 3-year (36/39 month) certs anyhow - no different than what will be required for 4 & 5 year durations under current rules.

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.

>
>Now that Microsoft have made their announcement about SHA-1[0], I would like to discuss and then ballot a change to reduce the maximum certificate lifetime in the BRs to 3 years sooner than >originally planned. (This is BR section 9.4.) This is something that we have been wanting to do and have agreed to do, but legacy concerns meant that the transition date to 3 year issuance was >originally set for April 1st 2015.
>
>However, due to the SHA-1 announcement, more than 98% of certificates[1] used on the public Internet are going to have to be replaced within just over 3 years anyway. (Assuming that "works in >Windows" is a requirement that everyone has for their secure website.) So now seems like a very good time to move the date, without some CAs who do more long-life issuance feeling they are >being unfairly penalised.
>
>As a reminder: the primary benefit to the industry of shorter certificate lifetimes is that we can ensure blanket coverage of security innovations in a shorter timeframe without requiring customers >to make unplanned certificate changes. In other words, it improves the agility and ability of the CAB Forum to make things better.
>
>So, my proposal (I will draft a formal ballot after we have discussed it
>more) is that we change section 9.4.1 and alter the occurrences of "1st April 2015" date to "1st January 2014", and change the "39" to a "36".
>36 months from 1st January 2014 is 1st January 2017, and this dovetails nicely with the date announced by Microsoft when Windows will stop recognising SHA-1 certs.

Speaking as a CA that sells 4 & 5 year duration certificates, changing the date to 1/1/2014 doesn't give me nearly enough time to cleanly transition away from the longer durations.  My current plans are to stop selling 4 & 5 year duration certificates no later than Jan 1, 2015 in order to allow customers purchasing these certs time to get them issued and cover any problems that might require reissuance.  I would suggest a 6-month grace period from the time the ballot passes, allowing CAs a few months to stop selling followed by a few months for clean-up.

>
>Open questions:
>
>1) Do we carve out an exception for existing longer-lived SHA-2
>   certificates? I would prefer not, because:
>
> * the number of such certificates is small;
>  * we want to more quickly realise the agility benefits of having a
>    consistent maximum lifetime;
>  * browsers would like to be have the option of enforcing certificate
>    lifetimes programmatically with simple logic;
>  * We were going to change this in 16 months time anyway.
>
>However, there may be CAs who have views on this question they would like to put forward.

If we're talking about existing certs, I think this has minimal effect on the situation.  The new SHA-2 rules combined with this proposal still don't require CAs to replace 4 & 5 year duration certs until Jan 1, 2017, so browsers couldn't enforce the certificate lifetime much sooner than under current rules which allow it to be enforced on April 2, 2019.  Meanwhile, CAs who issued these certs with "unlimited reissuance" would be forced to modify terms with this small set of customers.

>
>2) Do we say 36 months, or 39? I cannot remember what the arguments are for 39 months over 36, so perhaps those who made them would care to review them for us. I think "3 years" is easy to >understand, and fits with the MS dates well, given that we are now in mid-November.

I agree with others, this needs to be 39 month.
>
>3) I am curious as to whether any CAs are actually needing to take advantage of the "continuing issuance exception" in the latter part of section 9.4.1. It requires a system that "fails to operate if >the Validity Period is shorter than 60 months". My gut tells me that there must be very few systems like that indeed. Does anyone have information to report on this question?

Under the current rules, GoDaddy is likely to need to utilize this exception for a few months to meet a contractual requirement for one specific legacy system that will be retired in mid-2015.
>
>Gerv
>
>
>[0]
>http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx
>[1] Citation needed; but I've seen this quoted in several places _______________________________________________
>Public mailing list
>Public at cabforum.org
>https://cabforum.org/mailman/listinfo/public