2016-08-04 Minutes
Minutes – August 4, 2016 CA/Browser Forum Teleconference
Attendees: Alex Wight (Cisco), Atsushi Inaba (Globalsign), Ben Wilson (Digicert), Cap Hayes (Cisco), Doug Beattie (Globalsign), Geoff Keating, Apple, Gervase Markham (Mozilla), JC Jones (Mozilla), JP Hamilton (Cisco), Jody Cloutier (Microsoft), Josh Purvis (Cisco), Kurt Spann (Apple), Li-Chun Chen (Chunghwa Telecom), Peter Bowen (Amazon), Rick Andrews (Symantec), Robin Alden (Comodo), Ryan Sleevi (Google), Tim Hollebeek (Trustwave), Tyler Myers (GoDaddy), Virginia Fournier (Apple), Wayne Thayer (GoDaddy).
Read Antitrust Statement
Roll Call completed
Agenda reviewed – no changes
Approve Minutes of July 21st. There were no changes suggested on the call. The following day, Ben suggested minor edits by email, which will be incorporated in the Minutes as posted.
Ballot status: Kirk reported that Ballot 173 (removal of requirement to cease use of private key) had passed by a large margin on July 28, and reminded Members that they would probably need to make corresponding changes to their CPSs and Subscriber Agreements within 45 days (i.e., by Sept. 11, 2016)
Kirk noted that Gerv had posted a pre-ballot for Ballot 174 (amending BR 9.16.3 regarding procedures a CA should follow when the BRs are in conflict with local law), and suggested the Members should review the pre-ballot before it is formally started.
Kirk then raised the draft ballot on requirements for SRV names. The sponsor Jeremy was not on the call to give an update. Kirk noted that an entire section, BR 4.2.2, was deleted in the ballot, and asked why that was included in this draft ballot. Peter stated that this section had been relevant when Internal Name certificates were allowed, but is no longer relevant now that the period for Internal Server names has expired, and so should be removed. Ryan said this is part of ongoing cleanup of the BRs as provisions expired, and noted that the final sunset date for Internal Name or Reserved IP Addresses under BR 7.1.4.2.1 is October 1, 2016, when all unexpired certificates must be revoked.
Deadline for disclosure of subordinate CAs in SalesForce. Peter asked if Mozilla was going to announce a new, extended deadline for CA disclosure of all subordinate CAs in SalesForce, noting that various sources had noted subordinate CAs not yet listed by the previous June 30 deadline. Gerv stated that Mozilla had not taken action against CAs for undisclosed subordinate CAs after the deadline because Mozilla staff were busy with other projects and also wanted to make sure there were no errors before taking action. Mozilla is now discussing what actions to take. Gerv emphasized that all CAs should make certain they have disclosed all subordinate CAs in SalesForce to avoid future problems.
SHA-1 Procedure: Lessons Learned? Kirk asked the Members for any “lessons learned” from application of the existing SHA-1 exception process to date.
Rick noted that the one application had been completed, but the current rules said an applicant had to wait a minimum of 10 days for a response. He questioned whether a 10 day minimum is too little or too much. Running the Marc Stevens analysis program didn’t take too long – could the review process be shortened next time? Ryan said 10 days was a minimum for Google, as it performed other tests of its own, had to deal with the applicant’s OU issues, and the issuer had issues of its own that delayed completion of the review. Ten days is necessary for feedback from the community.
Gerv noted that the current procedure states the notBefore date for the proposed SHA1 cert may be up to 14 days in the future to accommodate the review time, but wondered if this was too restrictive – there could be cases where the notBefore date might need to be more than 14 days to allow additional time for review. Ryan agreed that having more lead time was a goal, but the idea that the request could only be submitted with 14 days left was either due to unintentional wording or a misinterpretation (subsequently clarified below). Peter said the 14 day maximum might come from how the CA’s CPS is structured, and not from the BRs or the procedure.
Ryan clarified that the 14 days comes from the request being able to set the notBefore up to 14 days in the future from the submission of the request. This is to avoid situations where a CA submits a request with the notBefore as the same day at the request, but the CA’s CP/CPS has a statement about how they set the notBefore relative to when they issue the certificate, which won’t happen until the end of discussion. This allows at least two weeks of discussion without the risk of another CPS violation, but Ryan didn’t think that concern was terribly significant, since by issuing SHA-1, they’re already going to be violating their CP/CPS.
As the Baseline Requirements don’t require CA’s make this statement, Ryan said it was a concern only if the CA made such a statement in its CP/CPS.
Gerv asked if the procedure should change 14 days to 28 days to allow more review time and greater flexibility (if a CA is concerned about violating its notBefore CPS provisions, the CPS can simply be amended for a short period if desired). Ryan said he didn’t see a problem with this.
Rick asked what would happen if review were completed in less than 10 days – could the certificate be issued earlier than 10 days? Gerv said if a CA wants a notBefore date of 10 days, the CA can set it at 10 days, but the CA can’t change it later. Or with a change, the CA can choose 28 days if it wants to, and then live with that. Ryan said there was a danger of a dual CPS violation in choosing 10 days or 28 days depending on the CA’s CPS, but said this issue might be more hypothetical than real – do CPSs even specify maximum notBefore dates now?
Gerv then noted there could be other alternatives – during the recent review, Phillip Hallam-Baker had suggested serial numbers be generated using “strict construction” for greater security. Should this change also be considered for future requests? Tim Hollebeek said more cryptanalysis was needed before making this change, as strict construction is more predictable so may not be more secure. Ryan also said he was concerned that CAs may not implement strict construction correctly, and it would be better if CAs introduced entropy-based numbering in their systems. Peter agreed with Tim that more analysis was needed, and raised further concerns related to the truncation of hashes, since they need to be truncated to sit within the 159 bits available in the serial. He also raised a concern about unrelated hash attacks; would it be better to use SHA-1 in this serial construction as well? Perhaps this would be better for IETF feedback as a draft RFC explaining a formal construction, to get broader feedback.
Ryan pointed out that unrelated hash attacks were largely related to hashing the same message (such as in the case in TLS’s concatenated hashes), rather than the cascade of independent hashes.
Gerv said consulting with IETF probably was not worthwhile, as the window for special issuance of SHA1 certs was closing.
Ryan offered some lessons learned. First, while there was only one sample, the applicant seemed not to understand the dangers from continued use of SHA1, so maybe there should be more industry education. Second, the applicant made the statement that the SHA1 certificates were not being used in modern systems, but they were in fact being used on modern platforms. Third, in the future there should be analysis of using the certificate switching mechanism – for example, there are open source solutions from Cloudflare and others for certificate switching, and applicants should examine these options first. This will be an additional question in the future.
Peter stated the recent application showed we need greater coordination between the Forum (which promulgates the BRs) and other groups that set their own guidelines. For example, the PCI Council (payments industry) does things differently. If multiple certificate policies apply to a common community (e.g. when payment terminals using the same root set as web PKI, cable boxes, etc.), there needs to be better coordination. It may be inappropriate to apply the same roots to solve multiple scenarios and products.
Rick noted that PCI evolved alongside Web PKI, and in many cased PCI customers and others simply grabbed existing trust store roots without telling the CA. The process evolved without much CA input. Peter noted that outside of the browsers involved in the Forum (who therefore are involved in coordinating with CAs), there is very little in the way of alternative root programs (e.g., for devices), and other users are simply copying the Mozilla roots store for these other devices. Can the Forum give these other groups some guidance to avoid future problems?
Ryan thought there was an opportunity for the Forum to offer guidance. Kirk suggested the Forum come up with and publish a list of non-trusted roots that could be used by others (devices, etc.) that would still be WebTrust/ETSI audited at least as to common security issues (data centers, etc.) for assurance, and recommend use of these roots with implementation guidelines.
- New Members. Kirk noted that Cisco had applied for membership as a CA in September 2015, completed all requirements, and was accepted. Later, Cisco delayed in signing the updated IPR agreement, and its membership was suspended. Cisco has now signed and submitted the current IPR agreement. Kirk suggested that Cisco should now be restored to Member status, and asked if there were any objections. There were no objections, and so Cisco is again a full Member of the Forum.
Kirk then reviewed the status for membership of ComSign. ComSign previously submitted all necessary documentation, but there was a question whether its current WebTrust for CAs was conducted according to the most recent, applicable audit guidelines. ComSign conferred with its WebTrust auditor, who submitted additional documentation correcting the audit guideline version to the most current and reaffirming that the most recent audit met these guidelines. Kirk suggested ComSign be confirmed as a Member, and asked if there were any objections. There were no objections, and so ComSign is now a Member of the Forum.
Governance Change working group update. Kirk noted that the working group would have a face-to-face meeting at Google’s offices in San Francisco on Aug. 9th. He noted that Dean had prepared an agenda, and asked Ben if there was any further update. Ben said there was no further update.
Validation Working Group Status: Ballot 169 – Updated domain validation methods. Kirk noted that Ballot 169 was now in the voting period, which would expire on Friday, and urged all Members to vote.
Procedure for election of new Chair and Vice-Chair. Kirk noted that on the last call, Members had asked Dean to outline the upcoming process for election of a new Chair and Vice-Chair, which Dean had done by email dated August 2. Dean noted his terms ends October 21 and Bylaw 4.1 says the Forum should start the lection process at least 60 days before that, and also presented the following summary table:
| Date | Period | Activity |
|---|---|---|
| Aug 4 | 7-28 days for Chair | On CABF call, review election process and announce nominations for Chair are open (for 14 days). Send email to management list also. |
| Sept. 1 | 7-28 days for Vice Chair | Announce close of nomination for Chair and start of nomination period for Vice Chair is open (for 14 days) Ask Chair nominees for election statements by Sept. 8 |
| Sept. 8 | 14 days (regular ballot period) | Start ballot for election of Chair – one week comment, one week voting (public if only one nominee, private voting if multiple nominees) |
| Sept. 15 | Close of nominations for Vice Chair. Ask for election statements by Sept. 22 | |
| Sept. 22 | Close of voting period for Chair, announce results | |
| Sept. 22 (don’t want 2 ballots running at the same time) | 14 days (regular ballot period) | Start ballot for election of Vice Chair – one week comment, one week voting (public if only one nominee, private voting if multiple nominees) |
| Oct. 6 | Close of voting period for Vice Chair, announce results |
Kirk asked for comments or questions about the process, but there were none.
Policy Review Working Group. Kirk asked Ben for any updates. Ben said on the last call the working group discussed possible solutions when the “locality” for a subscriber in a smaller jurisdiction was in conflict with the current BR requirements. Ben had posted a possible solution to the public list, and Robin had posted a response. The working group will continue on the issue.
Fall Face-to-Face Meeting – October 18-20, 2016, Redmond, Washington. Kirk noted the approaching meeting dates, and asked Jody if there were any updates. Jody said he needed a complete list of attendees for planning purposes, and asked Members to add their names to the wiki very soon if they are attending.
Any Other Business. Kirk asked if there was any other business to discuss, but there was none.
Next meeting. Kirk noted the next Forum teleconference would be on August 18th.
Adjourned.