CA/Browser Forum
Home » All CA/Browser Forum Posts » 2016-06-09 Minutes

2016-06-09 Minutes

Minutes June 9, 2016

Attendees: Andrew Whalley (Google), Atsushi Inaba (Globalsign), Ben Wilson (Digicert), Bruce Morton (Entrust), Dimitris Zacharopoulos (Harica), Doug Beattie (Globalsign), Eddy Nigg (Startcom), JC Jones (Mozilla), Jeff Stapleton (Wells Fargo), Jody Cloutier (Microsoft), Jos Purvis (Cisco), Ken Myers (US PKI), Kirk Hall (Trend Micro), Li-Chun Chen (Chunghwa Telecom), Mads Henriksveen (BuyPass), Moudrick Dadashov (SSC), Peter Bowen (Amazon)Peter Miscovic (Disig), Rich Smith (Comodo), Rick Andrews (Symantec), Ryan Sleevi (Google), Tim Shirley (Trustwave), Tyler Myers (GoDaddy), Virginia Fournier (Apple).

  1. Roll Call completed.

  2. Antitrust Statement was read by Kirk

  3. Agenda Reviewed – no changes

  4. Minutes of FTF of May 26, 2016. Kirk reminded the members that not all draft minutes have been uploaded, and asked any member who still was drafting minutes to upload them to the wiki as soon as possible.

  5. Ballot status:

Proposed Ballot 170 – Amended Sec. 5.1 of the Baseline Requirements. Ben said the ballot had been posted to the public list, and summarized the response he posted to Ryan’s comments, which stated where each proposed addition to the Baseline Requirements had come from (e.g., a NIST guideline, etc.) He has created branches on GitHub for various sections (5.1, 5.2, everything else) the working group is considering for easier review and so people can see what’s coming.

Kirk mentioned that there were many “no provision” sections in the BRs because we switched to RFC 3647 format to make it easier to review CPSs for against the BRs for compliance, and asked if the Working Group ever rejected any possible new requirements stated in a reference document, or always accepted what it found to insert on a BR section where there was no provision. Ben said many sections had been rejected or greatly shortened, and only those believed useful and probably acceptable to all had been included.

Peter asked whether the Working Group was evaluating whether anything at all was necessary for a “no provision” section of the BRs, or could the section be left empty. He pointed out these are requirements, not just optional guidelines, so we should be sure we are inserting language that should be actual requirements. Ben said yes, the WG had been considering that, and was only inserting new provisions that it thought every CA should be following. Ben mentioned that Ballot 170 was in the one-week comment period, and that voting would start about one week from now.

Ballot 169 – Domain Validation Ballot. Jeremy was not on the call, so there was no update.

Ballot 171 – Updating ETSI Standards. Ben stated there was a conversation going on the public list, which was perhaps the best place for it. Peter agreed saying it had just started on the public list. Kirk asked if it was worth outlining what the main issues were – were the parties addressing each other’s concerns? Ryan said yes, the parties were focused on the issues.

Ben said he could help by creating a red line version of the draft changes. Peter said it was not clear a red line version would help, the issue was more what is required and where to put the requirements – in the BRs or elsewhere? Also, the parties were deciding what requirements were equivalent.

Ryan said the issue is that ETSI standards have more diversity with layers on top of each other – but the question is, which ETSI requirements meet the root program requirements? What ETSI requirements are equivalent to the three sets of WebTrust audit requirements? Plus, which ETSI documents should be relied on to determine the quality of auditor? Red lines won’t help – there needs to be agreement on the requirements.

Jody said the issue had been covered well at the last F2F meeting in Bilbao, especially as to qualification of the auditor. He had sent a request to the ETSI governance group asking for an equivalence table, which perhaps could be incorporated in standards or requirements.

Ryan said that would help, but we also need to clarify which versions of ETSI requirements apply (-1 or -2). He though the -1 versions were clearer, and it would be better to assert compliance with the -1 version.

The discussion will continue on the public list.

  1. Governance Change working group update

Ben stated the Working Group had met, and he had circulated links to the meeting minutes. The Working Group is slowly narrowing down what it wants to do, including the Working Group scope in particular. On the next call, the Working Group will discuss how to start a new CABF working group.

The Working Group has discussed forms of IP agreements, formats such as the W3C IP model and management structure above its working groups. There would have to be a mechanism at the upper level to work on technical management and coordination among subordinate working groups. The group is still small enough at the CABF member level that the Forum can continue as “direct democracy” and not go to a representative model.

Virginia said there was opposition in the Working Group to having more than one IP agreement format among the various Forum working groups, as this could cause confusion.

Ben agreed, saying the Working Group had tentatively concluded the Forum and all subordinate working groups would need to use the same IP agreement. If the IP agreement is participation-based, the Forum would need bright line definitions of what “participation” was, then keep lists of who was participating in each Working Group on the website. We would also need a procedure on how participants could publicly leave a Working Group and stop participating. Following the W3C model would probably be easiest.

  1. Membership Application GDCA. Kirk stated that both he and Dean had reviewed the membership application and supporting documents of GDCA, and GDCA appeared to qualify for membership. He asked for comments, but there were none. After hearing no objections, Kirk said Dean would notify GDCA that it had been added as a Member of the Forum.

  2. SHA-1 draft proposal: comments and timing. Andrew noted Google’s proposal was on GitHub, and he could provide further information. Google is not proposing to adopt this proposal as a CABF policy or BR amendment, but was just looking for agreement among browsers for a common root program requirement to avoid multiple program requirements, with the goal that the proposal would be something that CAs and customers could meet. Andrew acknowledged that Microsoft might want less information than Google wants from applicants, and indicated the Google proposal was the minimum Google would accept.

Jody said at the F2F meeting everyone wanted one process for all browsers, and that the process discussed did not include many of the steps in the process Google posted. At the F2F, everyone agreed that risk avoidance was the main point, to be addressed by the technical cryptographic requirements.

Ryan noted that there were other considerations not discussed at the F2F meeting that are important to Google, such as how did this occur and how can everyone avoid problems in the future when existing standards are deprecated and users must move to new standards within a timeframe. He also stated that it appears new groups (not just financial processors) are also coming forward and asking for SHA-1 exceptions for themselves. All deprecation processes have been painful – we need additional information now to avoid similar problems in the future.

Jody said he didn’t think the best way was to ask for information from the subscriber – rather, it’s better to figure out these deprecation problems in the Forum. The discussion at the F2F meeting was intended to hash out these program requirements, and he was frustrated to see new requirements in the Google proposal. What if different browser programs have conflicting requirements? The most restrictive browser could end up hurting its brand if interim SHA-1 certs work in all other browsers. The purpose of this program is not to punish people.

Peter said the discussion had been useful, but it also comes down to what Andrew said at the start – that Google did not propose to put this program in the BRs or the Forum, but instead planned to impose it as a Google root program requirement. If each browser program is slightly different, that could be ok.

Jody countered that he thought the browsers had already agreed on a common program at the F2F, and changes now made him question whether these discussions had been useful or not. Security for the new SHA-1 certs was the most important thing.

Ryan said he didn’t understand the F2F discussions as being the last word on the program. There had been substantial agreement on the technical requirements, but other requirements had not been discussed.

Jody noted that the Google proposal had not been sent out in advance of the F2F meeting, so it couldn’t have been discussed, and it was a mistake to rehash now what had been agreed at the meeting. He concluded that it sounded like each browser would simply have its own program, which was too bad for the industry.

Kirk asked Andrew if all of the proposed Google questions to subscribers would really create useful information or not. For example, “When did you learn of the SHA-1 deprecation?” could result in an answer of “3 months ago” or “a year ago, but we forgot,” etc. – how was that helpful to avoiding future problems? Andrew said Google could certainly review the questions again to make sure they would produce useful information.

Jody noted that CAs who issue SHA-1 certs under this program will take an audit hit, so it’s not like we are giving CAs and their customers a free pass on this. Peter said Jody’s comment was correct – getting a qualified audit is already an incentive to CAs to avoid future deprecation problems like this. He also noted that a CA that issues SHA-1 certs will get a qualified audit report whether it follows various root program requirements or not, so why follow the requirements? Ryan said CAs will need to follow the root program requirements in order to avoid the risk of having their roots dropped by the browsers from their trusted root stores.

Kirk asked what comes next? Will there be a discussion among browsers on the Forum’s public list? Jody said Microsoft didn’t intend to do that, and would just move forward with its own program as previously discussed.

  1. Validation Working Group Status – No report

  2. PAG IPR – Updates and Cisco status. There was no report from the Working Group, but Josh Purvis of Cisco said its legal team and patent counsel had reviewed the current CABF IPR agreement, and Cisco would likely sign it soon without asking for any revisions.

  3. Policy Review Working Group Status – no report

  4. Information Sharing Working Group – no report

  5. Any Other Business – There was no other business.

  6. Next meeting on June 23rd

  7. Adjourned

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