[cabfpub] SHA-1 changes and certificate lifetimes

[Tom Albertson]

Gerv wrote:
[1] Citation needed; but I've seen this quoted in several places _______________________________________________

An appropriate reference for the north of 98% figure for the installed base of SHA1 certs would be the academic paper out of the University of Michigan, "Analysis of the HTTPS Certificate Ecosystem", Table 9 at  http://conferences.sigcomm.org/imc/2013/papers/imc257-durumericAemb.pdf.  They performed a very wide scan of certs with findings that correlate to our private scans.

Tom

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Gervase Markham
Sent: Wednesday, November 13, 2013 2:27 AM
To: CABFPub
Subject: [cabfpub] SHA-1 changes and certificate lifetimes

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.

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.

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.

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?

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