2013-11-21 Minutes
Notes of meeting
CAB Forum
21 November 2013
Version 1
1. Roll Call: Ben Wilson, Mert Ozarar, Atsushi Inaba, Lila Kee, Caroline Oldenburg, Eddy Nigg, Tom Albertson, Gerv Markham, Wayne Thayer, Mads Henriksveen, Geoff Keating, Rick Andrews, Kirk Hall, Rich Smith
2. Agenda Review: Agenda approved as published.
3. Approval of Minutes of 7 Nov 2013: Minutes approved as published. Ben will re-circulate email from Iñigo asking about CA involvement with key generation for EV certificates and new EN regulation.
4. Ballots: Status Reports on Ballots 89, 103 and 107.
Ballot 89: Rick said that he and Sigi have had comments going back and forth with Sigi making suggestions for the document. He has made some additional comments and Rick will try to incorporate those this week. The current draft is saved on the wiki.
Ballot 103: This ballot concerns OCSP and must-staple. Ben has held off on trying to push the ballot forward again because he thought that we should have agreement with IETF about an OID, or we could use the CABF OID, but there’s nothing that really identifies that that’s official either. This may need to be another discussion to continue on the list.
Ballot 109: Ben has proposed to remove the Implementer’s Note paragraph and nobody had an opinion one way or the other, so that would just be removed. Before the ballot is proposed again, Ben will recirculate the current redlined versions of both the EV Guidelines and the Baseline Requirements to Mads, Gerv, Kirk, and Iñigo for their comments and endorsements.
5. News: Microsoft Retirement of SHA1: Ben noted that Renne of Identrust had asked about legacy SHA1 Root CAs and SHA1 Intermediate CAs sign certificate status responses / revocation information. Tom said it would be best to send the questions directly to him and Kelvin. SHA1 questions will be answered on the blog page, but they’ll also be collected into a special page dealing with SHA1 retirement. Rick had three questions or comments. First, it appeared there was a misstatement in a blog post that said, “SHA1 code signing certificates that are time stamped before 1 January 2016 will be accepted until such time…”. What was meant was that “Code” that was timestamped (not certificates). The second item was whether on January 1, 2017, Windows would reject all timestamping certificates with SHA1? Rick added that for timestamping there will be a need to transition from older platforms that may not be able to handle SHA2, so by 2017 timestamping services might need to timestamp with SHA2 but still run SHA1 so that incompatible legacy systems still work. Tom said he was not sure about incompatibilities and that they would need to dig into that more. And third, what systems are RFC6277-compatible? Officially, only SHA-1 is supported by OCSP under RFC 2560, but RFC 6277 was to support OCSP algorithm agility, so we need to know about plans for OCSP requests and responder certificates with SHA-1. Tom asked for Rick to send the question to him and Kelvin, copy the Forum, and he would get a response to him and whomever is copied on the email.
Gerv said that we will likely keep discovering edge cases, so Tom might want to have a web page containing all updates with an explicit message telling visitors to check back again regularly for answers and updates. Tom said that it was his plan to create a page specifically for SHA1. Rick asked whether Gerv could track down the information for Mozilla on whether Firefox supports algorithm agility under RFC 6277. Gerv recommended that Rick ask the question on the Mozilla dev-tech-crypto list. Regarding Apple and RFC 6277, Rick will send Geoff an email.
6. Ballot 111 – Accelerate Max Certificate Lifetime Reduction Timetable: Gerv said that he has a circulated a draft ballot, which Eddy has endorsed, and he is looking for another endorser. Eddy said he would like to see another browser vendor endorse. Gerv explained that as of January 2014 any SHA1 certificate with a certificate lifetime of 3+ years will have to be replaced because on 1 January 2017 it will stop working because of SHA1 retirement. Assuming that the overwhelming majority of certificates presently in use on the Internet are signed with SHA1, this January they will all have an effective lifetime of three years. Members of the CA/B Forum are aware that “but for” the sunsetting in April 2015 of longer-life certificates under the Baseline Requirements for the subscribers of some CAs, publicly trusted SSL certificates are allowed to have a certificate lifetime of no greater than 39 months. However, SHA1 retirement now gives us the opportunity to bring forward that date, because the usefulness of these long-lifed certificates will now only be three years. Shorter-life certificates improve SSL ecosystem agility because when we make changes we want those changes to take place without having to wait a long time for legacy certificates, and a 3-year turn-over cycle is better than having to wait for 5 years.
Wayne said that he understands the logic behind the desire to go to shorter certificate lifetimes, but proposed Ballot 111 takes away extra time that exists in the current rules to make relatively smooth transitions away from these certificates. If this ballot passed today, we’d have only 6 weeks to implement it. That means that all of those certificates would have to be removed. If you look at all of the resellers who are selling them, that would be an additional problem, and considering the time that it takes for a certificate to be sold and issued, you would need to add on some additional time. Wayne said he planned on spending a lot of the next year transitioning those certificates to shorter lifetimes in a smooth way. Some resellers may still be selling 5-year SHA1 certificates, because a reseller doesn’t sell a certificate based on its signature algorithm. Wayne prefers April 1 over January 1. Rick echoed Wayne’s concerns. It will take Symantec more code changes in a number of different places to shorten the lifetimes of SHA1 certificates. They have been frantically working on SHA1 issues, and the soonest they would be able to roll this out in an emergency fashion would be January or February so he prefers April 1 as well.
Eddy asked whether an alternative rule could specify that beginning January 1, any new certificate with a lifetime greater than 39 months would have to be SHA2? Rick said that would involve similar code changes. Eddy asked what the plans were for CAs that had already issued SHA1 certificates with validity dates past January 2017. Rick said that they will have to work with those customers prior to that time and swap out their SHA1 certificates with SHA2 certificates. Gerv’s plan would help reduce the number of SHA1 certificates that would need remediation leading up to 2017.
Tom said for comparison, Microsoft considered the effects on customers with authentication certificates signed with SHA1. They looked at whether they should try to halt the issuance of SHA1 long-lived certificates. They decided not to do that because those with certificates that will stop working are in a better position to address the issue in a timely fashion-like people in a leaking boat, their objective is not to let their boat sink, so they will already be taking reasonable steps to prevent leaks where they can. Gerv said that he understands about mitigation, but that this also applies to the implementation of SHA2, so he would like to move the date to April 1, 2014, and specify that on January 1, 2014 a SHA2 certificate cannot be longer than 39 months. For this SHA2 approach, no one’s existing systems should be affected.
7. Applications for Membership: ANF, Identsign, and Certinomis: Ben said that discussion was open for ANF, Identsign, and Certinomis, but due to lack of time remaining on the call we’d have to postpone discussion on National Trust Lists. He noted that the Identsign website does not provide any indication that it is in the business of providing PKI services. Also, the application for Identsign to the questions list submitted by Mr. James Burton was incomplete. It was recommended that because of these deficiencies the Forum inform Identsign to reapply once it has its roots embedded in a browser. It was recommended that the other two CAs-ANF and Certinomis-be approved as CA Members because they met the requirements.
8. Review of Website – cabforum.org/wordpress: Ben noted that he had been contacted by someone on the public list who had reviewed the website and had a comment about the display of text on the pictures used for navigation. Gerv suggested that black text be placed on a light background so that the text would be easier to read.
9. Any Other Business: None.
10. Next phone call: Thurs. Dec. 5