CA/Browser Forum
Home » Posts » 2016-09-15 Minutes

2016-09-15 Minutes

Final Minutes September 15, 2016 (v2, revised 9/29/2016)

Attendees: Alex Wight (Cisco), Arno Fiedler (D-Trust), Atsushi Inaba (Globalsign), Ben Wilson (Digicert), Bruce Morton (Entrust), Carolyn Oldenberg (Globalsign), Curt Spann (Apple), Dean Coclin (Symantec), Dimitris Zacharopoulos (Harica), Doug Beattie (Globalsign), Erwann Abalea (DocuSign), Jody Cloutier (Microsoft), Josh Aas (Let’s Encrypt), Ken Myers (US PKI), Kirk Hall (Entrust), Li-Chun Chen (Chunghwa Telecom), Mads Henriksveen (BuyPass), Patrick Tronnier (OATI), Peter Bowen (Amazon), Peter Miscovic, (Disig), Phillip Hallam-Baker (Comodo), Ryan Sleevi (Google), Tim Shirley (Trustwave), Virginia Fournier (Apple), Wayne Thayer (GoDaddy), Wendy Brown (FPKI).

(Vice Chair Kirk Hall presided because Chair Dean Coclin was in a location where he could listen only.)

  1. ** Roll Call**

  2. Read Antitrust Statement

  3. Review Agenda – no changes

  4. Approve Minutes of Sept. 1st – Kirk asked if there were any edits to the draft minutes. There were no edits, and so the minutes of September 1 were approved and will be posted to the public list.

  5. Ballot Status

(a) Ballot 175 – Addition of given name – Kirk stated that Ballot 175 on given names had passed on September 8.

**(b) Miscellaneous edits to Ballot 169. ** Kirk noted that several members had noticed small typos in Ballot 169 as enacted, and had suggested corrections. Ben said he planned to make the corrections soon. Peter suggested maybe this issue of corrections should be delayed until after discussion of the IPR policy and our future plans on making any corrections. Gerv recalled that in the past we had some ballot language somewhere that gave the authors of ballots editorial discretion to correct errors, and that might apply here. Kirk stated that he had previously proposed amending the bylaws to allow something like a “consent ballot” where minor corrections like this would be formally proposed to the members, and then if no one objected within a certain period (e.g., 7 days), the corrections would be made. He thought a somewhat more formal process with a record of our actions would be better than simple ad hoc corrections with no record, and would bring up the issue in the Governance Change Working Group.

(c) OID needed for Test Certificate under Ballot 169. Dimitris pointed out that the new definition of Test Certificate under Ballot 169 called for the CA to include “a critical extension with the specified Test Certificate CABF OID” in the Test Certificates. Kirk asked if this was meant to be a single Test Certificate OID used by all CAs, or one unique to each CA. Dimitris said the natural interpretation was a single CABF OID used by all CAs, and thought the Validation Working Group should get an OID assigned. Doug agreed. Kirk noted the Validation Working Group recently became inactive, but that he would talk to Jeremy Rowley about scheduling new meetings.

**(d) Updating BR 3.2.2.5 (IP Address verification) to match Ballot 169. ** Doug had sent an email suggesting the validation methods for IP addresses in BR 3.2.2.5 be updated as appropriate to match the new validation methods for domain names in BR 3.2.2.4. Gerv agreed, and suggested the issue be sent to the Validation Working Group. Kirk will make this request to Jeremy Rowley, who was not on the call.

**(e) Draft Ballot 176 – Addition of CNAME verification to domain validation methods. ** Kirk noted that Jeremy had suggested amending BR 3.2.2.4 to allow authentication of domain names by CNAME. Jeremy was not on the call, but Kirk noted there had been discussion by email of Jeremy’s draft proposal, and asked if members were close to a resolution. Ryan said that Jeremy’s proposal was good, and Peter proposed some improvements. We are now waiting for Jeremy’s revised proposal before proceeding.

**(f) Draft SRV names ballot. ** Jeremy has also proposed a ballot allowing SRV names in certificates, but because he was not on the call, there was no update.

  1. Miscellaneous topics:

**(a) Inadvertent domain validation by email scanning applications. ** Peter pointed out by email that some email scanning applications click on links in emails to check for malware, and that any CA using the email validation method and confirming domain ownership or control via a simple one-click on a link in an email could end up with inadvertent domain validation when no person had actually clicked on the link to confirm. The better option is to require a second step, such as directing the subscriber to a page where another button had to be clicked to prove domain control, requiring the subscriber to copy and paste the Random Value in a field and send it back to the CA, etc. Kirk asked Peter if he wanted to propose a ballot to require steps by CAs to avoid inadvertent validation by email scanning applications.

Peter, Phillip, and Dimitris discussed various technical methods that might help prevent inadvertent validation. Peter said he didn’t think every possible danger needed to be addressed in the BRs, and simply wanted to alert CAs to this possibility. Dimitris said a BR requirements might not be auditable, and it might be better to post an article on the CABF website concerning “best practices” in this area.

**(b) Continuing the discussion on CAA. ** Rick Andrews had asked by email what the next steps should be for CAA, but Rick was not on the call so the discussion was postponed.

**(c) Questions regarding timestamping certificates. ** Dimitris noted that BR 6.1.7 prohibits CAs from signing certificates with root CA private keys, except for five specified exceptions. Exception (3) allows signing the following types of certificates with a root “Certificates for infrastructure purposes (e.g. administrative role certificates, internal CA operational device certificates, and OCSP Response verification Certificates).” Dimitris asked whether time stamping certificates qualified as “infrastructure purposes” and could be signed by a root. (CAs must operate an RFC-3161-compliant Timestamp Authority using a time stamping certificate under Sec. 16.1 of the Code Signing Minimum Requirements, which is not a CABF document.) He thinks the current BR language is ambiguous.

Bruce thought it was a bad practice to issue time stamping certificates directly from a root, and said that exception (3) could be amended to specifically disallow them, or we could remove all examples from exception (3). Peter noted that there may be some systems that “expect” a time stamping certificate to be signed by a root. Bruce said he would be surprised if it required the root to be a publicly trusted root for TLS certificates.

Wendy noted that because code signing certificates require a time stamping service, would there be the same objection to signing a time stamping certificate from a root if the root were not publicly trusted. Dimitris said that issue probably should not be decided by this Forum, as some key players in code signing certificates are not Forum members. The Forum only has jurisdiction over SSL certificate issues.

Bruce said members should look at the Code Signing Minimum Requirements document again – that document has all the specifications needed on this issue. Dimitris said that was not a complete solution, as he has seen some code signing certificate implementations that include a time stamping certificate that was signed by a publicly trusted SSL root. He thinks that’s a bad idea, and should not be allowed by exception (3) of BR 6.1.7.

Peter noted that the current BR 6.1.7(3) language could be interpreted to allow this practice, and asked if the language should be amended to prohibit it. Dimitris noted the current language already allows for OCSP response verification certificates to be signed by trusted roots. Peter noted that exception (5) for existing infrastructure situations had effectively expired as of June 30, 2016.

Ben asked what a CA would do if it wanted a time stamping certificate to be signed by a root. Peter said the CA could either sign the time stamping certificate from a sub-root of the trusted root, or sign from a non-trusted root. But he noted that signing a time stamping certificate from a trusted root does not appear to be a prohibited practice under the BRs today.

Dimitris reiterated that he believes signing a time stamping certificate by a trusted root should not be allowed under the BRs, and exception (3) of BR 6.1.7 should be amended to prohibit the practice. Bruce asked the question whether time stamping certificates qualified as “infrastructure” under exception (3), and said it seemed not. However, OCSP Response verification Certificates did seem like “infrastructure” that would qualify for exception (3). Dimitris said he would draft a ballot to prohibit signing of time stamping certificates by trusted roots.

  1. Governance Change Working Group update. Ben said the working group had met by teleconference on September 13, and was still working on a number of open issues remaining from the draft governance change proposal discussed on the last CABF call. These issues included a discussion of the meaning of “affiliates” and how the IPR policy would apply to affiliates, and also whether the IPR policies would apply to all forms of participation in working groups or subcommittees, or not apply in certain limited cases where it’s not clear at the start that any proposals will result that could involve IP.

Virginia said the working group had a difference of opinion on this point, and she believes the IPR policy should strictly apply to all CAB Forum activity, including involvement in a particular working group or its subcommittees – that’s how the W3C IPR policy applies, for example. If the IPR policy doesn’t apply at the start of a discussion, but the discussion soon turns into a proposal involving IP, then the members can never know for sure if they will be protected by the IPR policy and receive a royalty free license.

Ben noted that the current IPR Policy applies to all activities, which is what we are trying to change. Peter noted that under the draft proposal, members must clearly participate in a working group and any of its subcommittees for the IPR Policy to apply with respect to that working group/subcommittee. In further discussion, it was explained that the IPR Policy would only apply to members participating in a particular working group, and that members would not have patent obligations with respect to working groups they do not participate in.

The next meeting of the Governance Change Working Group will be on September 27.

  1. Validation Working Group Status. Kirk noted that Jeremy Rowley had suspended further meetings of the Validation Working Group after the passage of Ballot 169, but it would have to be restarted to deal with the new issues raised on the call today. He will talk to Jeremy.

  2. Policy Review Working Group. Ben said the Policy Review Working Group was reviewing other standards to see if the Forum should adopt additional requirements to strengthen CAs. At present the working group is reviewing all the places in the BRs where the words “CA” and “Root CA” are used to find multiple meaning for the terms, and perhaps adopt new terms for clarity. Dimitris said that “Root CA” generally means an organization that functions as a certification authority, and “root certificate” generally means an X509 certificate, but not always, which can be confusing. The working group will come back with a proposal.

  3. Application of current IPR policy. Virginia discussed a presentation she had sent to members on what the Forum’s IPR Policy currently requires. In essence, theForum should prepare new or amended Guidelines in the following order: (1) circulate draft ballots adopting or amending Guidelines, (2) send out Review Notices, (3) members identify patents with Essential Claims, if any and file Exclusion Notices within Review Period of 30 or 60 days, as applicable, and (4) proceed to a vote on the ballot if no Exclusion Notices are received. If Exclusion Notices are received, then (5) the Forum should appoint a Patent Advisory Group (PAG) to consider the notices and possible resolutions, after which a vote may be held. The Forum should follow this sequence exactly to get the benefits and protections of the IPR Policy.

Kirk then stated that he and Dean would soon be forwarding a detailed memo on this subject outlining how the Forum should readopt its current Guidelines to be in compliance with the IPR Policy. Peter noted that the members had voted on Ballot 169 and received two Exclusion Notices after the ballot, which meant that members did not know of the exclusions when voting, although under the IPR Policy members should have been made aware of the Exclusion Notices before voting on this ballot. Virginia stated we would likely need to form a PAG to evaluate the Exclusion Notices received. Kirk said there was some question of whether any past ballots would need to be readopted. Virginia stated that all members were now on notice of possible patent infringement claims relating to the Exclusion Notices filed for Ballot 169, and should check with their attorneys to see what the implications are for them.

  1. Voting implications after CA or browser merger. Kirk noted that there were some pending mergers of CAs or browsers, and this presented the question of whether both merged companies should still vote in the Forum (or instead only one vote should occur). He noted that Bylaw 2.2(b) says “Only one vote per Member company shall be accepted; representatives of corporate affiliates shall not vote.” Gerv said that Mozilla had outlined the relationship between WoSign and StartCom based on public documents in a posting, and suggested members could see the details for themselves. He noted that the Forum’s IPR Policy has a definition of “affiliate”, and asked if the Bylaws had one. Kirk said the Bylaws use the term affiliate when discussion voting (members and their affiliates only have one vote), but the Bylaws have no definition of affiliate.

Peter noted that the same issue could arise from the pending merger of Opera and Qihoo 360 once the transaction has closed. He also stated that in some cases a CA and a browser could be affiliated – Amazon has a CA division, and a separate Silk browser division, for example (which are separate legal entities under common Amazon ownership). Kirk suggested this issue should be referred to the Governance Change Working Group for proposals.

  1. Ballot 177 – Election of Chair. Kirk noted that voting started today for election of a new Chair, and that the candidates were Ben Wilson and Kirk Hall. Voting will end on 9/22/16. Dean has outlined the procedure for members to submit their votes by separate email to Don Sheehy and Clemens Wanko who will tabulate the votes and announce the result.

  2. Ballot 178 – Election of Vice Chair. Kirk noted that the nomination period for Vice Chair opened a week ago, and would close that day. So far there were two nominees: Ben Wilson and Phillip-Hallam Baker. Election statements from the candidates are due by 9/22/2016.

  3. Any Other Business – Kirk noted that the registration list for the Fall Meeting in Redmond, WA (Oct. 18-20) was closed, but Dean and Jody have a waiting list, if anyone else is interested. He said that Dean and Jody had called for Agenda items.

  4. Next Forum teleconference on Sept. 29th

  5. Adjourn

Latest releases
Code Signing Requirements
v3.8 - Aug 5, 2024

What’s Changed

Full Changelog: https://github.com/cabforum/code-signing/compare/v3.7...v3.8

S/MIME Requirements
v1.0.6 - Ballot SMC08 - Aug 29, 2024

This ballot sets a date by which issuance of certificates following the Legacy generation profiles must cease. It also includes the following minor updates:

  • Pins the domain validation procedures to v 2.0.5 of the TLS Baseline Requirements while the ballot activity for multi-perspective validation is concluded, and the SMCWG determines its corresponding course of action;
  • Updates the reference for SmtpUTF8Mailbox from RFC 8398 to RFC 9598; and
  • Small text corrections in the Reference section

Network and Certificate System Security Requirements
v2.0 - Ballot NS-003 - Jun 26, 2024

Ballot NS-003: Restructure the NCSSRs in https://github.com/cabforum/netsec/pull/35

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).