CA/Browser Forum
Home » All CA/Browser Forum Posts » 2017-04-13 Minutes

2017-04-13 Minutes

Minutes for CA/Browser Forum Teleconference 13 April 2017

Attendees: Arno Fiedler (D-TRUST), Atsushi Inaba (GlobalSign), Ben Wilson (DigiCert), Bruce Morton (Entrust), Christopher Kemmerer (SSL.com), Curt Spann (Apple), Dean Coclin (Symantec), Dimitris Zacharopoulos (Harica), Doug Beattie (GlobalSign), Frank Corday (Trustwave), Gervase Markham (Mozilla), JC Jones (Mozilla), Jeremy Rowley (DigiCert), Jos Purvis (Cisco), Kirk Hall (Entrust), Leo Grove (SSL.com), Li-Chun Chen (Chunghwa Telecom), Masakazu Asano (GlobalSign), Patrick Tronnier (OATI), Peter Bowen (Amazon), Peter Miscovic, (Disig), Rich Smith (Comodo), Rick Andrews (Symantec), Ryan Sleevi (Google), Tarah Wheeler (Symantec), Tim Hollebeek (Trustwave), Tyler Myers (GoDaddy), Virginia Fournier (Apple), Wayne Thayer (GoDaddy).

  1. Roll Call
  2. **Read Antitrust Statement **
  3. **Review Agenda. ** The Agenda was approved.
  4. a) Approve Minutes of CABF teleconference of March 16, 2017. The Minutes were approved.

b) Complete F2F meeting minutes: Kirk noted that Minutes had not yet been submitted for the following recent F2F meeting segments, and asked the people who had agreed to provide Minutes to do so as soon as possible and upload them to the wiki. He also noted that the leaders of the various breakout sessions for three Future of Web PKI segments had been asked to write Minutes for their sessions, but he had not written down the discussion topics chosen for the sessions or the names of the leaders. Ben said he would listen to the recordings and find the topics and names, after which the leaders will be asked to complete Minutes for their sessions.

Missing Minutes: Dean – Governance Change WG, Jeremy – Validation WG, Doug– Microsoft Program Update, Liang – 360 Update, Eric Mill – GSA update, Andrew Whalley – The Role and Relationship of the Forum, Dean Coclin – Meeting 41 in Berlin, Germany and future meeting volunteers, Future of Web PKI – Part 1 (2 sessions) – (to be determined), Future of Web PKI – Part 2 (2 sessions) – (to be determined), Future of Web PKI – Part 3 (multiple sessions) – (to be determined).

  1. Governance Change Working Group update. Ben said the WG had a call the prior Tuesday and went through the Bylaws changes on a shared document, and has started to edit the sections on Working Groups based on the proposed new structure. He said all were welcome to help edit, and if they wanted the URL for the joint document to contact him. Virginia said she had not been able to be on the call, but would soon offer edits. Dean asked if the WG had tried using the WebEx account set up for the Forum by Cisco, and Ben said he would first try a dry run. Dean said this could be useful in editing the Bylaws, as all participants can view the same document.

  2. Validation Working Group update. Jeremy said the WG had met recently and finished up the domain validation methods, Ballot 190. A ballot on IP address validation methods was ready, and a ballot to require a commonName for all root and intermediate certificates was being considered. Two or three additional ballots are almost ready.

  3. Policy Review Working Group update. Ben said the WG had lost its time slot to another WG, and Ben and Dimitris agreed to set a new meeting time just before the next Forum teleconference. They are still working on uses of the term “CA” and related terms in the BRs.

  4. Patent Advisory Group (PAG) update. PAG Conclusion and publication – Kirk noted that the Ballot 182 PAG Conclusion and Minutes bundle had been sent to the Management list before the meeting. He reviewed the Conclusion, and said there was no need for the Forum to approve the Conclusion (as it is the report of the PAG). Unless there was an objection, Kirk planned to (1) post the documents to the Public mailing list, and also (2) post to the Forum’s public website. There were no objections. Kirk again said the PAG result had been very useful, and thanked Virginia and the others who participated.

  5. Ballot Status.

Ballots in voting period: Kirk noted the following ballots were now in the voting period. There was no discussion of the ballots.

a. Ballot 189 – Amend BR 6.1.7 to clarify signing by root keys (Dimitris) IN VOTING PERIOD (ends APRIL 13)

b. Ballot 194 – Effective Date of Ballot 193 Provisions (Chris): IN VOTING PERIOD (ends April 16)

c. Ballot 195 – CAA Fixup (Gerv) IN VOTING PERIOD (ends April 17)

d. Ballot 196 – Define “Audit Period” (Gerv) IN VOTING PERIOD (ends April 17)

Ballots in discussion period: Kirk noted the following ballot was in the discussion period, and asked if anyone wanted to discuss it.

e. Ballot 190 – BR 3.2.2.4 Validation Methods (Jeremy): IN DISCUSSION PERIOD (ends April 19).

Jeremy said the ballot was intended to restore the BR 3.2.2.4 validation methods to what it was after Ballot 169, but with a few modifications for issues identified. Ryan said that as worded, Ballot 190 would require CAs to revalidate all domains (and not reuse prior validation data) for any domain validation method that had been modified by Ballot 190.

Gerv asked if Ryan saw that applying on a per-method basis, so no revalidation would be required if there was no change to the method. Ryan said the BRs require domain validation at the time of issuance of each certificate at the time of issuance, but allowed reuse of data under certain circumstances. So previous data can be reused if the validation method has not changed under Ballot 190. However, methods such as demonstration of control via the website would have to be redone for all domains because of the change to the methods in Ballot 190.

Kirk asked Ryan how he interpreted Section 2 of the ballot, which says revalidation is not required for domains that were properly validated by the methods permitted before Ballot 190 so long as they are still within the permitted data reuse period, and indicated he didn’t agree with Ryan’s interpretation that domains would have to be revalidated if the methods had changed under Ballot 190. Ryan said he thought Section 2 was badly worded and had no meaningful force. He said Section 2 did not change the BR section requiring validation of every certificate at time of issuance and that any change needed to update the BR document itself; in his opinion, Section 2 was null and void. There was further discussion of this issue. Ryan said more work on Ballot 190 was needed. Kirk asked if Ryan would submit his suggested edits to the Ballot. Ryan said the proponents of the ballot should address his concerns or he would vote no.

Gerv noted that Ryan’s position provided enormous disincentive to incremental improvements to methods of validation, and mentioned the web server method of validation as an example – the method requires the use of the .well-known path. If later the Forum decides to require the use of a sub-directory under .well-known – an incremental improvement – there will be enormous disincentive for CAs to agree to this if they have to revet all their customers. If every single incremental change invalidates all prior data, that will be a disincentive to change. The result could be that the validation methods get stuck, and no one will want to change them.

Ryan said Ballot 190 is just like Ballot 169, and said that Section 2 will have no force because it will not be part of the BRs. Gerv said if Section 2 is reworded in response to Ryan’s concern, but still made it clear that revalidation was not required, would Google vote for the ballot, or would it vote no because it wants to see revalidation? Ryan said Google would vote no even if Section 2 is reworded, because the current permitted period for reuse of validation data is too long to wait for revalidation using the new methods. If revalidation is not required in some fashion by Ballot 190, Google may adopt it as a root program requirement and treat reuse of the data as certificate misissuance even if permitted by Ballot 190.

Gerv suggested it might be wise to take each method individually and not as a group, as the level of change varied from method to method, and to allow previous validations to be reused for some. Ryan said Google was most interested in seeing the new methods for website validation implemented quickly, as they have seen multiple instances of improper validation using the current method and leading to misissuance, which is unacceptable. But Google might be open to allowing reuse of validation data for other methods. Gerv suggested the drafters of Ballot 190 might want to consider that information.

Ballots in IPR Review Period: Kirk noted the following ballot had passed during the voting period, and was now in the IPR Review Period. There was no discussion.

f. Ballot 193 – 825-day Certificate Lifetimes (Chris): IN IPR REVIEW PERIOD (ends April 22)

Ballot drafts: Kirk noted the following ballot drafts had been mentioned or circulated, and asked for an update on each.

g. Ballot 184 – RFC 822 Names and otherNames, SRV names. Jeremy said the ballot still needs some work and is not yet ready.

**h. Ballot 186 – Limiting reuse of validation information. ** Ryan said the discussion on Ballot 190 and Section 2 was useful, as the whole purpose of Ballot 186 was to reduce that loophole (i.e., reuse of validation data). The goal should clearly be that the reuse of validated information should be appropriate to the source of that validated information, meaning for example that the reuse of the file-based domain control method and data should not exceed 24 hours, and the reuse of domain name information should not exceed 7 days. The goal for many of the validation methods, except where there is a complex set of business and legal realities, should be limited to no more than one month. Kirk asked if Ryan planned to move forward with Ballot 186, and Ryan said yes, in parallel with Ballot 190. However, he said the introduction of Section 2 in Ballot 190 creates a conflict with Ballot 186. One possibility is to combine Ballots 186 and 190, or pass Ballot 190 without Section 2 and address the remaining matters in Ballot 186.

i. Ballot 191 – Clarify Place of Business Info. Jeremy said the ballot was ready to go, and needs endorsers. He thought there were two endorsers on the last Validation Working Group call but couldn’t remember who they were, and the sound quality of the recording was poor. He asked the endorsers to contact him so the ballot could proceed.

j. Ballot 192- Notary Clarification. Jeremy said the ballot was still in discussion and not yet ready.

**k. Require commonName in Root and Intermediate Certificates. ** Gerv said he had made revisions and just sent the ballot out again. He is looking for two endorsers.

l. RAs and Delegated Third Parties. Gerv said he had circulated a first draft ballot, and a revised second draft was coming. There was a discussion of the differences (if any) between an external RA and a defined Delegated Third Party. Ryan said the RA role performed by anyone except the CA is a Delegated Third Party. There was also a discussion of whether or not a QIIS (such as Hoover’s/D&B or a WhoIs aggregation service) would ever be considered a Delegated Third Party.

m. Expected ASN.1 grammar for BR & EV certificates. Peter said he is working on a ballot.

n. RFC5280-related Ballot. Ben said he had modified his prior draft ballot to focus only on the issue of underscore characters, and the ballot was ready. He was looking for endorsers. He noted the comments on the list about UTF-8 strings, and would amend his ballot accordingly.

o. Bylaws change – Membership requirements. Gerv had amended his first draft and recently posted it to the list. The proposal is in the pre-ballot stage, and he is looking for discussion but not yet for endorsers.

  1. Follow-up on F2F issues: Kirk noted the Forum had enjoyed very productive discussions at the recent Face-to-Face meeting hosted by Cisco in Research Triangle Park, and said he had listed the main discussion items from the Agenda. He wanted to see if the members who had led discussion of an issue planned any follow-up after the meeting. Kirk also said if he had forgotten any issues for which follow-up was appropriate, he hoped members would add them to the list.

a. Create process for adoption of post-SHA2 algorithms. Kirk said he planned to work with Phill to create some sort of document that proposed a procedure by which the Forum members could keep track of developments around current and future encryption algorithms and a plan for the steps the Forum would take in the event it is ever necessary to move from SHA-2 to a different algorithm. Ryan said he was doubtful of this approach. Peter said he was preparing a document the members could review on this issue.

b. SHA1 deprecation / lessons learned. Ryan said he further discussion would occur on the Public list.

c. Role and relationship of the Forum. No follow-up.

d. Code of conduct. Virginia said she had sent a proposal to Tarah (who is travelling) and hopes to have something ready for the members to consider on their next teleconference.

e. Revocation checking. Robin was not on the call, so there was no discussion of any follow-up.

f. Use of Trello board to keep track of Forum projects. Peter said if he has any follow-up to propose, he will send it in as a future agenda item.

g. Updates to RFC 5280 / process for exceptions. Jeremy said that Ben’s draft ballot on RFC 5280 was the follow-up for this item.

h. Other “Future of Web PKI” sessions. Ben said he will compile a list of the presenters for each of the topics discussed and we can then ask them if they think any follow-up is appropriate.

i. Other F2F issues. There were no other F2F issues.

  1. Next F2F meeting: June 20-22, 2017 Berlin (D-Trust) – Kirk noted that Arno had posted a range of hotels on the wiki and recommended that members who planned to attend should book their rooms now. There are no special booking codes.

Oct. 3-5, 2017 Taipei (Chunghwa Telecom) – Li-Chun said there had been a change in the meeting hotels, and details would be available on the wiki.

  1. Any Other Business. There was no other business.
  2. Next call April 27, 2017.
  3. Adjourn
Latest releases
Code Signing Requirements
v3.8 - Aug 5, 2024

What’s Changed CSC-25: Import EV Guidelines to CS Baseline Requirements by @dzacharo in https://github.com/cabforum/code-signing/pull/38 Full Changelog: https://github.com/cabforum/code-signing/compare/v3.7...v3.8

S/MIME Requirements
v1.0.7 - Ballot SMC09 - Nov 25, 2024

This ballot includes updates for the following: • Require pre-linting of leaf end entity Certificates starting September 15, 2025 • Require WebTrust for Network Security for audits starting after April 1, 2025 • Clarify that multiple certificatePolicy OIDs are allowed in end entity certificates • Clarify use of organizationIdentifer references • Update of Appendix A.2 Natural Person Identifiers This ballot is proposed by Stephen Davidson (DigiCert) and endorsed by Clint Wilson (Apple) and Martijn Katerbarg (Sectigo).

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