2016-12-22 Minutes

Minutes for CA/Browser Forum Teleconference 22 December 2016

Attendees: Atsushi Inaba (Globalsign), Ben Wilson (Digicert), Dean Coclin (Symantec), Doug Beattie (Globalsign), Gervase Markham (Mozilla), JC Jones (Mozilla), Jeff Ward (BDO, for WebTrust), Ken Myers (US PKI), Kirk Hall (Entrust), Li-Chun Chen (Chunghwa Telecom), Peter Bowen (Amazon), Peter Miscovic (Disig), Rich Smith (Comodo), Rick Andrews (Symantec), Ryan Sleevi (Google), Tarah Wheeler (Symantec), Tim Shirley (Trustwave), Tyler Myers (GoDaddy), Wayne Thayer (GoDaddy)

1. Roll Call

2. Read Antitrust Statement

3. Review Agenda – there were no changes to the Agenda.

4. Approve Minutes of teleconferences of Dec. 8, 2016. The draft Minutes were approved for posting.

5. Discuss WebTrust issues (Jeff Ward, BDO, for WebTrust). Kirk had invited Jeff Ward to participate on the call to discuss certain WebTrust audit questions that had arisen on the prior call.

Jeff first addressed BR WebTrust v2.1, effective for audit periods starting on or after Dec. 1, 2016, and available here: http://www.webtrust.org/principles-and-criteria/item83172.aspx. Sec. 4.1 on Verification of Domain Control provides:

The CA maintains controls to provide reasonable assurance that as of the date the Certificate was issued, the CA obtains confirmation in accordance with the SSL Baseline Requirements Sections 3.2.2.4, 3.2.2.5, 3.2.2.6 and 4.2.2 related to the Fully-Qualified Domain Name(s) (including wildcard domains and new gTLDs (generic top-level domains)) and IP address(es) listed in the Certificate.

Appendix D contains additional guidance:

Appendix D: CA/B Forum effective date differences

SSL Baseline Requirements

The following Baseline Requirements have effective dates later than the effective date of these Audit Criteria. Refer to details and instructions below for guidance on how to address these as part of an audit: ***

Reference: 3.2.2.4

Effective Date: 1 March 2017

Guidance:

Baseline Requirements v1.3.8 replaced the entirety of the domain validation requirements in this section with new requirements.

For certificates issued on or before 28 February 2017, the auditor is directed to consider the domain validation requirements in Section 3.2.2.4 of Baseline Requirements v1.3.7.

For certificates issued on or after 1 March 2017, the auditor is directed to consider the domain validation requirements in Section 3.2.2.4 of Baseline Requirements v1.4.1.

This version of the BR WebTrust audit criteria is based on BR v1.4.1, which is complete through Ballot 175 and so includes Ballot 169 (effective March 1, 2017) that restricts domain validation to ten stated methods. However, the BRs are being re-enacted through Ballots 180 – 182 to comply with the Forum’s IPR Policy. Kirk pointed out that if Ballots 180 and 181 pass on January 7 but the vote on Ballot 182 is delayed while Exclusion Notices are examined by a Patent Advisory Group, then BR 3.2.2.4 will be altered from what is was under Ballot 169 and the guidance under BR WebTrust v2.1, Appendix D will no longer be accurate. Jeff was asked how auditors would deal with this.

Jeff said there would likely be a communication to auditors pointing out the change to the BRs since BR WebTrust v2.1 was adopted by WebTrust, and it was not likely that CAs would be held to the language of BR 3.2.2.4 as it existed under Ballot 169 starting on March 1, 2017. The audit will only follow what the current BRs require of a CA at any given time.

Peter said that one browser had publicly stated that no matter what BR 3.2.2.4 said with modifications under Ballots 180 and 181 (which again allow CAs to use “any other method” for domain validation so long as the CA makes certain determinations), that browser expected CAs to limit themselves to the ten validation methods of Ballot 169 only. He asked if WebTrust would follow this browser’s expectation when conducting BR audits on and after March 1. Jeff said browser rules are important, but a BR WebTrust audit would be based on the BR WebTrust criteria which are based on the BRs. It had happened before that the most current version of WebTrust audit criteria did not keep up with changes to the BRs or other CABF requirements. The basic rule is that if a CA is in compliance with the then-current CABF requirements, that would control over any outdated WebTrust audit criteria. Since the WebTrust criteria are updated from time to time based on CABF requirements, auditors test for compliance with those requirements as referenced in the document (each updated version references what version of CABF criteria they are based on).

Gerv asked what would happen in the audit report if a CA was in compliance with applicable CABF requirements, but not in compliance with outdated WebTrust audit criteria – would the CA receive a clean (unqualified) audit report? Jeff said different auditors might treat this differently (some might include a statement or observation to that effect in the report, known as an emphasis of matter in the audit report, others might not), but it would not cause an audit report to be qualified. WebTrust will likely clarify Appendix D before March 1 to reflect any further changes to BR 3.2.2.4 in Ballots 180 or 181.

Peter again noted one browser’s expectation that CAs will limit themselves to only the ten methods of Ballot 169, so CAs may want to talk to root programs if they want to use another validation method.

Jeff noted that some Forum members had asked for changes to the Network Security requirements of the BR WebTrust audit criteria (e.g., as to days versus quarterly, etc.) to deal with potential ambiguities. WebTrust was looking to the Forum to provide guidance as to the types of changes and clarifications they wanted in the Network Security audit criteria, as WebTrust could only act with guidance from the Forum.

Ben said DigiCert was conducting an internal review of the Network Security requirements and “red-lining” them in areas for possible simplification or clarification. DigiCert will circulate the red-lined document when completed and get input from other members. Peter noted that some auditors feel the Network Security audit language is unclear and should be changed, and there may be conflicting interpretations of current language from different auditors. Jeff said WebTrust would be most comfortable making changes with guidance from the Forum on what revised standards it wanted incorporated.

Kirk asked Jeff what WebTrust criteria were under development. Jeff said the Code Signing audit requirements [which are not based on a CABF document] were 90% complete and a draft would be released soon, and a version 1.6 of the EV Code Signing audit criteria (reformatted to RFC 3647 format) would become effective January 1, 2017. WebTrust is also developing Practitioner Guidance intended to help new auditor practitioners conduct a WebTrust audit as well as provide clarification to experienced auditors on complex issues, and was also circulating a draft of criteria for WebTrust for RAs to deal with cases where external RAs are used and must be audited – this document is not as far along. Many of the criteria for this document were taken from existing RA audit requirement in WebTrust for CAs where the CA itself performs the RA function.

Jeff then reported on the “continuity of audit period” issue that had come up at a recent WebTrust auditor meeting in San Francisco. A standard practice among auditors when a client receives a qualified audit (i.e., fails to meet some criteria) was to give the client time to remedy the problems, then conduct a successful point-in-time audit, and only then re-start the period of time audits. The reasoning is that clients who discover after the end of an audit period that they were not in compliance and receive a qualified audit showing a need to change procedures would not want to pay for a continuous period of time audit for the current audit period knowing it will again result in a qualified audit (at least to the date the problems were addressed and the point in time audit is passed). As a result, there would not be continuous period of time audits for the client, but instead there would be a gap for the period from the end of the prior period of time audit to the time of a successful point in time, with no reporting on that gap period.

Four of the browsers attended the meeting and said they were not comfortable with this approach, but instead wanted continuous period of time audit reports, even if that meant there would be two back-to-back qualified audit reports for the reasons discussed above. The browsers stressed they could often accept qualified audit reports so long as they know what the problems were, and that the problems were being remediated. What they didn’t like was being in the dark during any gap period – what if additional problems arose during this gap period? As a result, Jeff said WebTrust auditors represented by the WebTrust Committee, BDO, Deloitte, EY, and KPMG, were advised of this browser preference, and there would not be gap periods when a qualified audit arises.

Finally, Kirk recalled that a few years ago there had been discussion of getting WebTrust audit criteria updates on a regular 12-month cycle, e.g., as of July 1 of each year the existing CABF requirement would be noted and the corresponding WebTrust audit requirements would be updated through July 1, with the new criteria to be effective as of the following January 1. Kirk recalled that one problem was that ETSI required a longer time for updates (e.g., 9 months). He asked Jeff if WebTrust had considered any kind of regular annual audit criteria update cycle. Jeff said WebTrust intended to focus on Forum requirements changes at its fall meeting each year to do updates to WebTrust audit criteria. Kirk thanked Jeff for his contributions to the meeting.

6. Governance Change Working Group update. Dean said the WG had met and hoped to complete edits to its proposal, but still had one section left to review at its next meeting. After that, the proposal will be transmitted to the CABF for discussion. The proposal does not contain actual Bylaw changes to accomplish the governance changes under discussion, but rather is a roadmap of detailed concepts so that the WG can get Forum feedback before doing the hard work of drafting new Bylaws, etc. He hoped to finish the proposal early in January.

7. Validation Working Group update. Kirk and Tarah provided an update. The WG continues to work on draft ballots (many of which are listed below) to prepare them for the full Forum, including CNAME verification, amending methods for IP address verification, SRV names, RFC 822 Names and Other Names, and clarifications to the domain validation methods of BR 3.2.2.4 as passed by Ballot 169. There was also a discussion of changing the BRs and EVGL to deal with countries that do not use state or province in addresses, as well as changing the EVGL for jurisdictions where different types of businesses are registered at different levels of government.

8. Policy Review Working Group update. Ben said the WG is working on modifications to the BRs to clarify what is intended when the term “CA” is used, and a draft would be circulated soon.

9. IPR Policy Task Force update. Kirk noted he had circulated Minutes for the most recent Task Force call. In summary, he noted Virginia had presented a ballot concept that would have included a 7 day discussion period, 7 day straw ballot (to avoid possible IP fishing), a 30/60 day review period, and a 7 day voting period for final approval. Several on the Task Force call had thought that process took too long for most ballots, which do not result in any Exclusion Notices. As a result, Kirk though Virginia might be modifying the ballot concept so the 7 day straw vote before the IP review period might be treated also as the final approval vote if no Exclusion Notices were filed during the review period – but he wasn’t certain of the details. Once consensus is achieved, the new voting rules can be adopted in a simple 14 day vote, as no IP review period in required for Bylaws changes, and new ballots can begin.

Kirk also noted that Ballots 180-182 were still proceeding and that if any members wanted to file Exclusion Notices, they must do so by December 31. Peter noted only one CA had filed an Exclusion Notice for Ballot 182 to date, and asked if members needed to file again if they had previously filed similar Exclusion Notices in the past (e.g., for Ballot 169 earlier in the year). Kirk said that in his personal opinion members who wanted to make sure their Exclusion Notices would be effective under the IPR Policy should refile them by December 31. He also said members should make sure to use a form for their Notices like the template notice form he had circulated (as prior Notices might not be valid for a number of reasons, including the fact that no member had stated whether it was willing to license its IP, which was a requirement for Exclusion Notices under the IPR Policy). [Members should consult their own IP counsel on all these points before proceeding.]

10. Ballot Status. Kirk noted the following ballots are underway (Ballots 180-182) or are in the queue waiting to begin:

• Ballots 180-182 (Kirk, Virginia) – Review period ends 12/31/2016, voting starts 1/1/2017
• Ballot 176: BR 3.4.4.2 – CNAME verification (Jeremy)
• Ballot 179: BR 6.1.7 – Root signing time stamping certs (Dimitris)
• BR 7.1.3: OCSP responder certs (Wayne)
• BR 7.1.4.2.2 and EVGL 9.2.5 and 9.2.7 (Li-Chun)
• SRV names in certificates (Jeremy)
• Reuse of domain validation data after Ballot 169 effective date (Wayne)
• RFC 822 Names and Other Names (Jeremy)
• CAA (Gerv) – see prior CAA topic

He said he believed the voting procedures for new ballots would be agreed upon soon and would only take 14 days for approval in a CABF ballot, and so he encouraged members to get their ballots ready for introduction and discussion to clear the backlog.

11. CT Policy Days Update. This meeting is being organized by Ryan Hurst in Mountain View, CA in February for one of these dates: Feb. 7-8, Feb. 20-21, or Feb. 21-22. Tarah and others asked if a date had been chosen yet, as members need to know the date soon for calendar planning purposes. Kirk said he would email Ryan to ask if the meeting date had been decided.

12. Next F2F meetings: Kirk noted that hotel information had been added to the wiki for the March meeting in Research Triangle Park, NC, and recommended members make their reservations and also add their names to the list of attendees on the wiki for the meeting. Gerv said new information had been added to the wiki as to shuttles available from the airport to the hotel.

Kirk asked Dean about the status of the date poll he had published on the proposed June 20-22 dates for the meeting in Berlin. Dean said 25 members had already indicated they were available on those dates, and the host said other dates in June may not be available, so that meeting will be set for June 20-22. The upcoming meeting dates are therefore as follows.

21-23 March 2017 – Research Triangle Park, NC (Cisco)

20-22 June 2017 Berlin (D-Trust)

3-5 Oct 2017 (Chunghwa Telecom)

13. Any Other Business. Mozilla CT Policy: Kirk noted there had been discussion about Mozilla’s CT policy on the Mozilla list, and asked Gerv if he wanted to provide any update. Gerv recommended that people read the draft policy carefully as a whole, and respond to the policy as a whole, and not just parts. The discussion will continue, and the policy is not likely to be finalized for weeks or even months. Mozilla is open to suggestions of new goals and draft details in the policy, as its position is not yet fixed.

Kirk asked if a revised draft would be released soon based on comments to date, and Gerv said probably not until the new year. He noted that he had posited a “thought experiment” to the group on the Mozilla CT list – what would the pros and cons be of requiring all CT logs to accept all certificates for logging – is that a good idea, or not, and why? He would appreciate responses from members on this concept.

Kirk asked if Mozilla was planning to coordinate its acceptance on new CT logs with others who have CT programs, such as Google. Gerv said the Mozilla CT policy would be independent, and would always be open and transparent, but was likely to incorporate the Google list of accepted CT logs as a starting point. But the two programs would not otherwise be strictly linked. By keeping its CT policy open and transparent, other programs will be able to copy the program and Mozilla’s list of approved CT logs if they desire, just as occurs with Mozilla’s root program today.

There was no other business.

14. Next call on Thursday, Jan. 5, 2017

15. Adjourn