CA/Browser Forum
Home » All CA/Browser Forum Posts » 2016-01-21 Minutes

2016-01-21 Minutes

Minutes of CA/B Forum Teleconference – January 21, 2016.

Attendees: Atsushi Inaba, Ben Wilson, Billy VanCannon, Connie Enke, Davut Tokgoz, Dean Coclin, Doug Beattie, Gervase Markham, Jeff (Wells Fargo) Li-Chun Chen, Mads Henriksveen, Mat Caughron, Neil Dunbar, Patrick Tronnier, Peter Bowen, Peter Miscovic, Rich Smith, Rick Andrews, Robin Alden, Ryan Sleevi, Sissel Hoel, Tim Shirley, Volkan Nergiz, Wayne Thayer, Wendy Brown

  1. Antitrust Statement Read by Robin

  2. Roll Call completed

  3. Agenda Reviewed.

  4. Minutes of 7 January meeting: The minutes were approved and will be sent to the public list.

  5. Policy Working Group Ballot Status: The last call was cancelled so there are no updates. There was some confusion on ballot 159 which started voting but nobody voted as it was unclear that voting was underway. Ryan said that he and Sig had made comments but there were no responses. Ben said he will review the comments and fix the ballot.

  6. Proposed Sub CA naming ballot: Dean said that we had discussed this last time. Rick proposed using names that could be vetted using OV standards, rather than a generic trademark. Peter said that OV allows Tradenames, not trademarks. A discussion on “dba” names ensued. Dean said the intent of the ballot is to make it unambiguous to relying parties who the CA is that is named as the Issuer in the Intermediate. Peter said that they could use the trademark in the common name field as long as the “O” field was properly vetted. Rick said the word “generic” would be difficult to assess by auditors. Rick will continue to formulate the ballot.

  7. In-scope certs: A discussion was started on the list about what certs are in scope (any EKU, no EKU, specific EKU). Ryan said the BRs define these one way while some root programs, particularly Mozilla, have a broader scope, resulting in some confusion from some CAs as to what is actually in scope. The goal is to align the definitions so it is clear to all (idkp ServerAuth will be in scope). If there is no EKU, clients treat it as if Server Auth is there. In summary, any certs that can be used for SSL should be in scope. Ryan said that some intermediates had used a broader definition in the past and that those should be in scope. He said that it should be similar to what Microsoft proposed in their root rules whereby you would need a separate intermediate for email certs, for example, that could not be used for server auth. This will require restructuring some of the intermediates that are out there. He suggested we put this to a ballot to see what concerns are out there. Peter said he had posted something regarding the effective date which Ryan had expressed a concern. Peter asked for clarification. Ryan said that he didn’t want the ballot to suggest this was something new, as it had always been this way and didn’t want to have two sets of certificates out there that would get different treatment. Wendy said the Federal PKI has a different interpretation. Up until May 2015, the FPKI certificate profiles for subscriber signature certificates stated EKU need not appear. If included in a certificate that is specifically designated for use in a single application (e.g., code signing or signing content on PIV cards), the extension may be marked either critical or non-critical. If included in any other certificate (to support specific applications), the extension must include the anyExtendedKeyUsage value and must be marked non-critical. Additional key purposes may be specified. Although the anyEKU value is no longer required if EKU is present, the EKU extension itself is still optional in the digital signature certificates. Gerv asked if the certs have domain names. The answer was no. Gerv asked Ryan if he supported adding a domain name as part of the definition. Ryan was loathe to support that. He said the definition should be as simple as possible. Peter said names can look like unqualified names (especially a Unicode encoded name in the SAN). Peter asked Wendy if they are continuing to use anyEKU. She said it was not mandatory but some sub CAs are continuing to do so and hence passage of such a ballot would not be favorable. Some certificates also have been issued without any EKU, however that language has been taken out from the recent profiles. Further discussion will take place on the list.

  8. Membership Applications: Four membership applications were received. DocuSign purchased OpenTrust and has re-applied under the new name. A new IPR was submitted. No comments were voiced and hence the application was accepted. The second application was from ComSign. The audit report was a Point in Time audit, not a period report. As per prior applications, it was recommended that they be granted Associate member status until they submit their period audit report. The third application was from NCDC (Ministry of Communications and Information Technology, Saudi Arabia). Some concerns were raised on the list about some non-BR compliant items. Dean said the audit was not against the SSL B/L criteria, only WebTrust for CAs. Due to some questions on the audit, and to give some time for the reviewers to assess, it was decided to table discussion to the next call. The fourth application is from TrustCor who has presented their full WebTrust audit. There was no discussion and TrustCor was admitted as a full member.

  9. PAG Status: Ben said the draft ballot (157) was posted on the new IPR policy with an effective date of 15 February. The ballot will give companies 30 days to sign the agreement and 60 days to disclose patents. Ben will go out with the formal ballot.

  10. Validation WG Update: Peter was the only one on the call from that group and reported that some edits to the ballot had taken place. The major open topic was that the ACME spec had validation methods that are not aligned with the ballot. The group needs someone who understands that spec to step up and help re-work the ballot.

  11. Code Signing WG Update: The working group met last week (first meeting since ballot results). We are looking for a new home for the document by talking to several constituents. In the meantime some changes were submitted and the group is adding those to keep the document as correct as possible. A further update will be given after the Scottsdale meeting.

  12. Policy WG Update: No further update.

  13. Information Sharing WG Update: Ben had circulated an edited MOU to the working group now that the US CyberSecurity Information Sharing Act had passed.

  14. Other Business: Attendance for Scottsdale is now up to 35 people. Dean is formulating the agenda and is looking for topics from members. The guest speaker will be announced next week. Dates for Bilbao meeting: The week of May 16th and 23rd are the finalists. There are slightly more YES responses for the 23rd however the 16th wasn’t added until later and some people did not respond. Wayne indicated he could only do the week of the 23rd.

  15. Next teleconference scheduled for February 4th

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