2014-08-21 Minutes
Notes of Teleconference – CA/B Forum 21 Aug 2014
Antitrust Statement: Read by Ben.
Roll Call: Tim Shirley, Patrick Tronnier, Ryan Sleevi, Ben Wilson, Cecilia Kam, Robin Alden, Atilla Biler, Mads Henriksveen, Sissel Hoel, Doug Beattie, Dean Coclin, Tim Hollebeek, Jeremy Rowley, Wayne Thayer, Tom Albertson, Stephen Davidson, Kirk Hall, David Barnet, Rich Smith, Kelvin Yiu, Atsushi Inaba
Agenda Review: Reviewed. Mads noted a mistaken cross-reference in agenda item 6 – it should have referred to Section 4.1 of the Bylaws.
Approve Minutes: Minutes of 7 August 2014 were approved. Ben mentioned that he should have the draft face-to-face minutes ready for circulation soon.
Ballot review: No ballots are pending. Other ballots under discussion and preparation by Forum members were discussed as follows:
Pre-Ballot 132 (EV Code Signing Timestamp Validity Period): This proposal is to change the time stamping validity period of EV code signing from 123 months to 135 months. To accommodate key usage periods of 10 years for timestamping validity in Japan. Steve Roylance has asked for another endorser besides Digicert. Ben will send out the draft ballot to the list with a blank left for another endorser.
Pre-Ballot 125 (CAA): Rick is not on the call, but as a follow-up to our last call, Ben looked at the last comment from Kirk. He was concerned that we only addressed CAA in the warranty section of the BRs and the language should be that the CA does certain things. Kirk said it would be better as a firm requirement. Ben wants the firm-requirement language to meet Stephen’s concerns that it not be a lock-step requirement. Ben will circulate a revised draft ballot to get the ball rolling again, but wanted to alert people that there would be some email traffic on the topic as we get the kinks worked out – attempting to address the issue by putting it in both the warranty and in a requirements section, but only as a disclosure requirement and not as a mandate to implement CAA.
Ballot 131 (Update to Verified Method of Communication): This ballot is to address concerns expressed by Microsoft and Mozilla during voting on Ballot 122. Cecilia is making the motion, and Jeremy and Rich have endorsed. That ballot will go out today.
Ballot 123 (Revalidation of Information): The EV WG has determined that this ballot is ready to go out, but there are edits inside it that would change again based on Ballot 131, so the EV WG decided that ballot 123 would go out after ballot 131 is voted upon in order to incorporate those changes.
Pre-Ballot 133 (EV Insurance): Ben is working on a proposal that would amend two sections in the EV guidelines. One section is where the EV Guidelines state that if the laws of the CA’s jurisdiction prohibit or conflict with a provision of the EV Guidelines or would cause the CA to violate the law, then the national law would supersede the Guidelines. He’ll add the insurance requirement to that section, in addition to the modifications of the insurance section that were previously circulated. He will circulate a draft ballot shortly and seek endorsers.
Nominations for Vice Chair and Chair
According to section 4.1 of the Bylaws, the vice chair is automatically nominated, so Dean has already been nominated as the Chair. However, nominations are now open and anyone can be nominated to run for the office of Chair. We’ve never done this before, so when nominations should close? Ben asked the group to discuss how they think we should proceed on time frames and steps. According to the Bylaws, the current term of officers ends on October 22. While the Bylaws say that the expiration of the term is when nominations occur, we shouldn’t wait until then. Robin suggested a two-week nomination period. Kirk suggested that the next step would be to decide then (during our next call) where to go from there, how to proceed with a ballot, etc. If there’s two contested races, then you would hold ballots for both. If we do a two-week nomination period, and no one is nominated as an opponent for chair, then we would close nominations and do some kind of ratification for a chair-elect. Since nominations are open, Dean would like to make a nomination for Vice Chair.
Dean nominates Atilla Biler from Turktrust. Atilla accepts.
DigiCert nominates Robin Alden from Comodo. Robin accepts.
Dean also nominates Kirk Hall from Trend Micro. Kirk will think about it and get back to the group. [He accepted.]
Nominations will stay open for 2 weeks.
Membership application for Entrust.
Dean has verified the application of Entrust and everything was in order. There were no comments in opposition to Entrust’s application. Therefore, and the group accepts membership of Entrust as a CA member.
Dean noted the recent discussion that we have had concerning the process of vetting members and approving members. The traditional way of doing this has been voice vote during our phone calls, but we should be able to do this over email because not everybody is on each call. It’s also better to have all CAs and browsers able to respond, and there is no advantage over this process by having it occur only during the call. It could have been done much easier over the email. Kirk has suggested a change to the bylaws to address this. Ben would also like something broader in writing somewhere in the Bylaws so we can point to it when questions over proceeding in this manner are raised. Kirk will take a look at this and provide feedback.
Public Release of Code Signing Baseline Requirements: We have received and incorporated comments from members, and the revised draft is almost ready to go out to the public. There is a revised cover page, which the Working Group is editing, so the public comment draft will be released very soon.
Upcoming Face-to-Face Meetings.
Meeting 33: Richard sent out an email indicating that he does not have a record of a hotel reservation for everyone who has indicated that he or she will be attending. So make sure you get back to him if you haven’t already. Also, if you’re going on the tour after the meetings, you should give him the information he has requested for the trip insurance for that tour. We need to start working on the agenda. We have received topics from Richard and others to put into the agenda. If you have additional suggestions, please send them to Ben. He will start putting things into slots. In the next few days he will send out a draft agenda.
For Tuesday’s working group meetings in Beijing, the EV Working Group will need approximately one hour to an hour and a half. Then the Code Signing Working Group will need another hour to hour and a half, depending on the comments that are received. The remaining time will be reserved for the Policy Review Working Group because it is the newest working group and there are significant things to review, such as the NIST CP and changes to the network security guidelines.
Meeting 34: Trend Micro has offered to host in Cupertino, CA, March 10-12, 2015. Anybody aware of a major meeting conflict should let us know now–we have to lock the dates in.
Meeting 35: Conny Enke has informed us that SwissSign has agreed to host us in Zurich, Switzerland, in June 2015. There are two dates that she recommends. Dean will send out a doodle poll–it seems to be an easier way to collect feedback and you get statistics at the end.
Any Other Business.
Google Deprecation of SHA1 – As discussed at the Mountain View F2F, Ryan noted that the following URL announces Google’s plans for the deprecation of SHA1- UPDATED on 5 September 2014 – see http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html
in a soon-to-be-released version of Chrome, most likely Chrome 39, which is about 12 weeks away. The post cited above describes the details. If an end entity certificate is valid after January 1, 2017, and SHA1 appears in any of the signatures that are validated (SHA1 can appear in the root-that will not affect anything), but if SHA1 appears in any digest algorithm, then Chrome users will receive a degraded UI, and any sub-resources they load will be treated as mixed content. The end-user experience will be the same as if they attempted to load http resources over SSL. So for this scenario, users will not be given an interstitial, but they won’t be getting a green lock – no EV indicator. If a certificate has a validity period extending beyond 2016, end users will be given a degraded UI, but it will not be treated as mixed content.
The motivation for this is that we agree with Microsoft’s Internet flag date and we want to raise awareness with users as they visit different sites. We also want to make sure that site operators are prepared to change certificates, at least between 2016 and 2017, to an appropriately strong algorithm. This does not reject certificates but just degrades the UI. One option, if a CA wants work around this UI degradation for a certificate that expires before 2016, the CA can issue the customer a new certificate with an expiration of 2015, then that will work within Chrome.
Based on our analysis of the CT database, some CAs will be more impacted than others. There will likely be more customers requesting SHA1 certificates that expire before those dates or that they will be requesting SHA256 certificates as replacements.
Chrome releases happen on a 6-week cadence. The cadence for Chrome 39 is roughly 12 weeks out. This change will be visible to users of our Canary Channel this week, users of the Dev Channel within a week or two weeks, users within the Data Channel at some point between 6 to 8 weeks, and users on the Stable Channel in 12 weeks. Because Chrome has multiple channels that users can opt into based on their desired level of usability or features, some users will be seeing this change very soon, but that group is generally small, whereas this will reach all Chrome users in about 12 weeks.
Kirk: Are you effectively outlawing SHA1 as of January 1, 2016?
Ryan: An expiration date of January 1, 2016, will cause a degraded UI, but it will not require user interaction to communicate with that site. A SHA1 certificate with an expiration after January 2017 will not work, and we support Microsoft’s position that no new certificates with SHA1 should be issued after January 1, 2016.
Kirk: So, when Chrome 39 is released, a certificate with SHA1 that is good until February 2016 will be degraded because it expires after January 1, 2016?
Ryan: Yes.
Kirk: So, you’re degrading SHA1 six weeks from now for people who have a SHA1 certificate that expires in 2016?
Ryan: For people that have a SHA1 certificate that expires after January 1, 2016, when Chrome access a site, the users will not see a green secured indicator. The holder of the certificate has a few options. The CA could reissue a certificate signed with SHA2 throughout the chain or the CA could reissue a SHA1 certificate that is capped at December 31, 2015. The CA could also issue a SHA256-signed certificate and allow the customer to decide when they want to transition to the SHA256 certificate. It does not require that the user immediately switch to the SHA 256 certificate.
Kelvin: What does the degraded user experience look like?
Ryan: The goal is not to treat it as an interstitial–the big scary red page of death. The 2016 trigger is just a change to the icon–it becomes a red lock with a stripe through it, similar to mixed content. Users aren’t required to directly interact with it. The 2017 trigger presents a red line indicator. They will be treated as mixed content. Passive mixed content, such as images, will be allowed. The icon for mixed content is a page with a yellow exclamation mark. Active mixed content, like XML HTTP requests or other forms of script will be blocked, and users will have to choose to allow it like they have to do with mixed content today, and if they do, it will be a red lock.
Kelvin: if I am going to a website that is pulling from a java script file, of some origin, and if that site has not updated their certificate, then Chrome will treat those cases as you have just outlined, depending on the certificate validity period?
Ryan: Correct. The mixed content spec that is being developed in the web apps group has this concept, and has some load conditions that are further explained.
Kirk: So, as of 12 weeks from now, any site using a SHA1 certificate that expires after January 1 2016 will get a red slash through their padlock?
Ryan: Correct. We’d appreciate feedback to the announcement at the URL provided above.
Kelvin: One data point. In the telemetry data that we have collected for IE, we are seeing an uptick in SHA2 certificates issued within the last six months. The share of SHA2 certificates went from 5% in December to about 27% as of July. It has plateaued since April at around 23%.
Ben: I think a lot of that has been GoDaddy switching over to SHA256.
Ryan: We’ve seen it plateau at around 30% and during the Heartbleed reissuance we also saw it go up then. We also saw some pretty substantial sites shift over to SHA256 along with many users upgrading XP to service pack 3. The goal is to make sure that site operators are aware and prepared and at least site operators should be aware that their certificate will no longer work on that 2017-01-01 date.
Network security requirements. Looking at the landscape of things involving the CA/Browser Forum, we need to prioritize work on network and certificate system security as part of our policy review for several reasons. This as part of the CP review working group, but there has been relatively low participation in this group up to now. The reason is that it ties together with a need to start working on cleaning up and improving the network security requirements–especially if anyone has any concerns about the audit requirements effective as of July 1 per Don’s message at face-to-face meetings. Hopefully that can be done as part of the working group, and that’s why we have 3+ hours set aside at the working group meeting in Beijing.
Poison Certificate Extension as part of BRs.
Ben: At the recent face-to-face we discussed this idea of a critical CABF extension as a way to limit the scope of the Baseline Requirements in situations where customers tell the CA that they need an SSL certificate but not for use with a browser. That conversation seemed to slip through the cracks without being continued, so where should we go from here, strategy wise? Are people still working on that idea?
Dean: Rick Andrews would be the one to respond on this.
Ben: The idea would be that there are certain things that use SSL that aren’t browsers. A critical extension would work to resolve some Baseline Requirement conflicts if the SSL-using system/application can still process the certificate (e.g. if they are not 5280-compliant). So, this may be the subject of a ballot for the BRs that says there is an exception here. If a customer wants to use SSL, and the CA can put a critical extension into the SSL certificate that will break it’s use by browsers, then assuming that’s the case as a technical, this “poison” extension, could be a solution. That was something we discussed at the last F2F. Ben will finalize the minutes of that discussion and circulate those notes.
11. Next phone call - Thurs. Sept. 4
12. Meeting adjourned