CA/Browser Forum
Home » Posts » 2016-08-18 Minutes

2016-08-18 Minutes

Minutes CABF Teleconference August 18, 2016

Attendees: Andrew Whalley (Google), Atsushi Inaba (Globalsign), Ben Wilson (Digicert), Bruce Morton (Entrust), Cap Hayes (Cisco), Curt Spann (Apple), Dimitris Zacharopoulos (Harica), Doug Beattie (Globalsign), Eddy Nigg (Startcom), Geoff Keating (Apple), Gervase Markham (Mozilla), JC Jones (Mozilla), Jeff Stapleton (Wells Fargo), Jeremy Rowley (Digicert), Jody Cloutier (Microsoft), Kirk Hall (Entrust), Li-Chun Chen (Chunghwa Telecom), Mike Johnson (Digicert), Neil Dunbar, Trustcor, Patrick Tonnier (OATI), Peter Bowen (Amazon), Peter Miscovic (Disig), Robin Alden (Comodo), Ryan Sleevi (Google), Tyler Myers (GoDaddy), Virginia Fournier (Apple), Wayne Thayer (GoDaddy).

  1. Read Antitrust Statement

  2. Roll Call

  3. Agenda Reviewed – no changes

  4. Minutes of August 4th. Ryan noted he had just sent out proposed edits to Sec. 7 of the Minutes of August 4. Kirk suggested the members defer approval of the Minutes as edited until the next CABF call so a revised draft could be circulated.

  5. Ballot status:

Draft SRV ballot – Jeremy said he would proceed with the draft SRV names ballot that was previously discussed if there was support from other members. Peter said he would take up the next draft of a ballot, as further edits were needed. He gave a brief explanation of the ballot – its purpose is to specifically allow CAs to include SRV names in a certificate if the customer want it – that is not permitted under the BRs today. Peter explained that SRV names are useful were the customer wants to specify not only the FQDN but also the specific service the certificate is to be used with (e.g., web server, etc.). The technical specifications are already laid out in one or more RFCs, but SRV names can’t be used by public CAs under the BRs today.

Ballot 173 – Modification of the subscriber requirement to cease use of private key. Kirk noted that this ballot had passed by a large margin, and would take effect after 45 days. That means that many CAs may need to modify their CPS and Subscriber agreements by Sept. 9, 2016 (unless they prefer to keep the more restrictive terms in place).

Ballot 174 – Compliance with local law. Kirk noted that this ballot is in the discussion period, and voting will start on Monday, Aug. 22. Gerv explained that this ballot amends BR 9.16.3 (Severability) to clarify a process by which a CA may comply with local law even though it conflicts with a provision of the Baseline Requirements, and lays out an improved method of how the CA can give notice of the conflict to the public and the browsers so they can decide what, if anything, to do in response. Gerv added that the current BR 9.16.3 is drafted in a way that it is never likely to be invoked.

Updated Version of BRs posted – Ben noted that he had just posted to the CABF wiki and to GitHub an updated version of the Baseline Requirements including all changes through Ballot 169 (domain validation methods), and invited other members to confirm that the information is correct. Kirk thanked Ben for his hard work on this and other projects.

  1. Ballot 169 (domain validation methods) and IP disclosure. Kirk stated that Ballot 169 on domain validation methods had been approved, and in response Dean had sent out the required IPR Review Notice to members by email on August 10. The notice states that the IPR review period ends on Sept. 15, 2016, so if members want to avoid granting royalty free licenses relating to Essential Claims, they should make the required IP disclosure notifications by that date.

Peter noted that the current IPR policy only requires members to send IP notices to the Chair, and asked if Dean would create a list of IP notices received and post it publicly so others could know what notices were received. Kirk said he would pass this request on to Dean.

Gerv asked what would happen if a CA has already posted an IP disclosure on an earlier version of the BRs (e.g., for an earlier version of BR 3.2.2.4 governing domain validation methods) that was previously changed by ballot – would the CA have to make the same IP disclosure again after Ballot 169? He expected the answer was yes. Kirk agreed the wisest practice was for a CA to re-post – otherwise, there could be risk.

Peter noted that our current IPR disclosure policy requires a CA to specify which section of a BR the CA’s claim of IP applies to. On this basis, even if a CA has reported IP for a particular BR section as to an earlier version of the BRs, once the BR language or section numbering changed, in his opinion a new disclosure was required. He noted that a new IP disclosure had been required following adoption of the updated IPR policy v1.2, but that according to the CABF wiki, only one new “active” IPR disclosure had occurred (from Symantec). Ben said that for historical reasons, we have been leaving previous IP declarations posted on the wiki. Jeremy noted that our updated IPR policy also redefined what was an Essential Claim, so more declarations will be needed now that we have eliminated the “any other method” subsection for domain validation methods.

Peter agreed, saying the current IPR policy provides that each permitted method must be evaluated on its own, meaning each domain validation method is an Essential Claim, and any conflicting IP must be disclosed. Ryan agreed. Peter noted that Ballot 169 added new sections and modified old sections, so that new IP disclosure requirements would probably be triggered as to all sections. Ryan added an example – suppose a CA had made an earlier conflicting IP disclosure for old domain validation methods 1-6 under IPR v1.2. Now, methods 1-6 have been rewritten, and we have new methods 7-10 – CAs should review the text of all ten methods to determine if they have a new duty to disclose (particularly as to validation methods 7-10, which are totally new). Peter added that BR 3.2.2.4 was totally reorganized by Ballot 169, so reference to any prior section number in a prior disclosure probably was no longer accurate, which would be another reason for renewed disclosure of conflicting IP in a disclosure.

  1. Governance Change Working Group update. Kirk noted that there had been a productive face-to-face meeting of the Governance Change Working Group on Aug. 9th, and that the Working Group had developed a set of tentative recommendation at the meeting which Ben had sent out by email on August 16. He asked Ben to provide an overview of the Working Group’s tentative recommendation for feedback, and Ben provided the overview. Gerv said that Mozilla was cautiously positive about the proposal, and congratulated the Working Group on its progress. He added that it seemed odd to name the TLS server certificate working group the “Web” Working Group versus “Server”, as its focus would be on server certificates, and suggested the name might be changed.

Kirk noted that the Working Group had received suggestions for creation of additional working groups beyond Web (or Server) Certificates, S/MIME Certificates, and Code Signing Certificates, but couldn’t recall the suggestions. Patrick said he had recommended also creating a Client Authentication or Devices Working Group.

  1. Validation Working Group Status – status of ballot on BR 7.1.4.2.2 – givenName and surname (IV or Individual Validated certificates). Kirk asked Jeremy for an update. Jeremy said he had just sent out his previous draft ballot to the list, planned to move forward with the draft, and was looking for endorsers to proceed.

  2. Policy Review Working Group – Kirk asked Ben for an update on the working group’s recent discussions. Ben said the group was considering email comments and drafts relating to changes requested by Chunghwa Telecom to deal with requirements relating to locality and state certificate naming protocols in some smaller political subdivisions. There could be conflicts with nomenclature standards of ISO.

[Immediately after the call, Ben updated the current status by email, stating that Li-Chun has requested an amendment to BR Section7.1.4.2.2d/e to make localityName and stateOrProvinceName optional when the subject:organizationName and subject:countryName fields are present if “(b) the country/jurisdiction specified by the subject:countryName field has a centralized registry that ensures that the organization name specified by the subject:organizationName field is unique in the entire country/jurisdiction.” He said the working group was still working on this. Similar changes would be needed in the EV Guidelines too.]

Peter stated there are also some CAs who are trying to follow another naming standard outside of the BRs (e.g., a government identity standard for tax purposes, etc.) which could be viewed as a BR violation. As an example, he mentioned a UK tax requirement some years ago to insert certain identifying data in a specific type of certificate. He said that the tax authority in Taiwan didn’t want CAs to insert data in the L or S fields as it wasn’t needed in Taiwan. Kirk wondered if a similar conflict with the BR requirements could occur with the new eIDAS certificate requirements in the EU, and Peter agreed.

Ben said the Policy Review Working Group would continue working on the issue.

  1. Any Other Business – Fall Meeting –Registration, call for Draft Agenda items. Kirk again stated the next face to face meeting would be on October 18-20 at Microsoft’s offices in Redmond, WA, and asked anyone who is coming but has not yet signed up to sign up on the wiki immediately to help Jody with meeting planning. He also asked the group to forward any meeting agenda items to Dean.

  2. Next meeting on Sept. 1

  3. Adjourn

Latest releases
Code Signing Requirements
v3.7 - Mar 4, 2024

S/MIME Requirements
v1.0.3 - Ballot SMC05 - Feb 20, 2024

Adding CAA.

Edit this page
The Certification Authority Browser Forum (CA/Browser Forum) is a voluntary gathering of Certificate Issuers and suppliers of Internet browser software and other applications that use certificates (Certificate Consumers).