CA/Browser Forum
Home » All CA/Browser Forum Posts » Minutes of the F2F 59 Meeting in Redmond, Washington, 6-7 June 2023

Minutes of the F2F 59 Meeting in Redmond, Washington, 6-7 June 2023

Meeting 59 Minutes

CABF Face-to-Face Meeting 59: Day 1 June 6, 2023

Attendance

Aaron Poulsen – (Amazon), Abhishek Bhat – (eMudhra), Adam Jones – (Microsoft), Adrian Mueller – (SwissSign), An Yin – (iTrusChina), Andreas Henschel – (D-TRUST), Aaron Poulsen – (Amazon), Aneta Wojtczak-Iwanicka – (Microsoft), Antti Backman – (Telia Company), Arno Fiedler – (ETSI), Ben Dewberry – (Keyfactor), Ben Wilson – (Mozilla), Brianca Martin – (Amazon), Bruce Morton – (Entrust), Chris Clements – (Google), Christophe Bonjean – (GlobalSign), Clint Wilson – (Apple), Corey Bonnell – (DigiCert), Corey Rasmussen – (OATI), Daryn Wright – (GoDaddy), Dave Chin – (CPA Canada/WebTrust), David Kluge – (Google), Dean Coclin – (DigiCert), Dimitris Zacharopoulos – (HARICA), Don Sheehy – (CPA Canada/WebTrust), Doug Beattie – (GlobalSign), Dustin Hollenback – (Microsoft), Ellie Lu – (TrustAsia Technologies, Inc.), Enrico Entschew – (D-TRUST), Eva van Steenberge – (GlobalSign), Fumi Yoneda – (Japan Registry Services), Georgy Sebastian – (Amazon Trust Services), Glaucia Young – (Microsoft), Hannah Sokol – (Microsoft), Hogeun Yoo – (NAVER Cloud), Hubert Chao – (Google), Ian McMillan – (Microsoft), Inaba Atsushi – (GlobalSign), Inigo Barreira – (Sectigo), J.P. Hamilton – (Cisco), Jamie Mackey – (US Federal PKI Management Authority), Janet Hines – (VikingCloud), Jeremy Rowley – (DigiCert), Joanna Fox – (TrustCor Systems), John Sarapata – (Google), Jonathan Kozolchyk – (Amazon Trust Services), Jos Purvis – (Fastly), Joseph Ramm – (OATI), JP Hamilton – (Cisco Systems), Karina Sirota – (Microsoft), Keshava Nagaraju – (eMudhra), Kiran Tummala – (Microsoft), Lakshmi Ramalingam – (Microsoft), Leo Grove – (SSL.com), Li-Chun Chen – (Chunghwa Telecom), Mads Henriksveen – (Buypass AS), Mahua Chaudrhi – (Microsoft), Marco Schambach – (IdenTrust), Mark Nelson – (IdenTrust), Martijn Katerbarg – (Sectigo), Matthias Wiedenhorst – (ACAB Council), Michael Guenther – (SwissSign), Michael Slaughter – (Amazon), Michelle Coon – (OATI), Mohit Kumar – (GlobalSign), Nargis Mannan – (VikingCloud), Nate Smith – (GoDaddy), Naveen Kumar – (eMudhra), Nick France – (Sectigo), Nicol So – (CommScope), Nitesh Bakliwal – (Microsoft), Pankaj Chawla – (eMudhra), Paul van Brouwershaven – (Entrust), Pekka Lahtiharju – (Telia Company), Peter Miskovic – (Disig), Raffaela Achermann – (SwissSign), Rebecca Kelley – (Apple), Roberto Quinones – (Intel), Rollin Yu – (TrustAsia Technologies, Inc.), Romain DELVAL – (Certigna), Ryan Dickson – (Google), Scott Rea – (eMudhra), Sissel Hoel – (Buypass AS), Stefan Kirch – (Telekom Security), Stephen Davidson – (DigiCert), Sven Rajala – (Keyfactor), Tadahiko Ito – (SECOM Trust Systems), Tahmina Ahmad – (Microsoft), Thomas Zermeno – (SSL.com), Tim Callan – (Sectigo), Tim Crawford – (CPA Canada/WebTrust), Tim Hollebeek – (DigiCert), Tobias Josefowitz – (Opera Software AS), Trevoli Ponds-White – (Amazon), Tsung-Min Kuo – (Chunghwa Telecom), Vijayakumar (Vijay) Manjunatha – (eMudhra), Vikas Khanna – (Microsoft), Wayne Thayer – (Fastly), Wendy Brown – (US Federal PKI Management Authority), Xiao Qiang – (GDCA), Xiu Lei – (GDCA), Yashwanth TM – (eMudhra), Yoshihiko Matsuo – (Japan Registry Services), Yoshiro Yoneya – (Japan Registry Services).

CA/Browser Forum Meeting

Approval of CABF Minutes from last teleconference

Leader: Paul van Brouwershaven (Entrust)

Minutes were approved.

Future face to face meeting schedule

Leader: Dimitris Zacharopoulos (HARICA)

Discussion outside the presentation: No further discussion.

Microsoft’s Trust & Distribution Services (Guest Speaker)

Guest Speaker: James Dunkelberger (Microsoft) and Ian McMillan (Microsoft)

  • Presentation link:* Not available

Bylaws updates part 1

Leader: Dimitris Zacharopoulos (HARICA)

Discussion outside the presentation

  • Dimitris: We have been working on this for a while. Ballot Forum-15 has been distributed. The discussion period ends June 16, 2023. Please provide comments in the thread. Dimitris plans to start the voting period right after the discussion period.
  • Clint had a few topics for discussion. He noticed that the Bylaws will be adopted under CC 4.0 and wanted to highlight that for Members to know. Also, should we change the voting percentages? Dimitris said he had two slides for new topics near the end of his presentation.

Specific topics from the slides were reviewed.

    1. Minimum Days to Review Minutes. There is a proposal that draft minutes be circulated at least 5 calendar days prior to a vote for approval. Dean asked what the issue is that we’re trying to address. Dean asked about the minutes for very short meetings. Does that mean we have to wait now 5 days for people to review very short minutes? Dimitris said that the purpose is to allow people some minimum time to review minutes before they are approved, and sometimes there are very extensive and complex minutes. It is very possible that some representatives are not present at the minutes approval meeting and cannot express their desire to postpone the approval of the minutes. There is a Google document that captures this issue. Dimitris said it’s not for subcommittee minutes. Paul also said that it’s possible some representatives are not available during a subsequent meeting and will not have time to review the draft minutes before they are approved. Dimitris said that he would proceed with the proposal as written and we could have more discussion on the mailing list.
    2. Alignment of WG Charters. We will take the S/MIME charter as a guide. We’ll try and fix the quorum issue. Dimitris asked whether we should use a single ballot to update all working group charters. Tim H. supported this concept of a single ballot. Clint wanted to confirm that these proposed changes would occur after Ballot Forum-15. He also said a single ballot would be good. Dimitris said that numbering would be added to charters to help identify sections. Ian asked what Dimitris meant when he said that quorum would be fixed. He explained that section 2.4 of the Bylaws discusses quorum, but in the working group charters, there is a different way to calculate quorum. They should be consistent regarding “active members” being the average number that attended the last three meetings. (They should both say that quorum is half of the active members.) Martijn said that the bylaws and charter are not consistent in the way they include “interested parties” as “Members.” So under the charter, you would have to count everyone to determine quorum and you’d never reach that in voting.
    3. Dimitris has a “part 2” to discuss tomorrow (re: cadence of releasing guidelines).
  • Clint asked about whether we should revisit the required voting percentages of 1/2 + 1 of Certificate Consumers and 2/3rds of Certificate Issuers? He also asked whether the list of previously qualified Associate Members should be cleaned up? He suggested that we remove the list of previously involved Associate Members. .
  • Dimitris said that the purpose of keeping the list of previous Associate Members was historical and to illustrate the types of organizations that we’d allow to be Associate Members.
  • Clint noted that in section 5.1.1 of the Bylaws, there is an incomplete sentence – “Minutes will be considered final … provided that …” (The sentence doesn’t finish properly.)
  • Tim said that it’s supposed to say that they’re automatically approved.
  • Clint asked about posting messages from the Management Email List publicly without permission of the author and whether that should be in the Code of Conduct.
  • Dimitris said he didn’t have a strong opinion either way on it. He said it could be amended to cross-reference the Code of Conduct.
  • Dean said it should stay in the Bylaws.
  • Tim said that it would already be considered a violation of the Code of Conduct.
  • Dimitris said we could make it more explicit that a violation of that Bylaws would be considered a violation of the Code of Conduct.
  • Tim agreed.
  • Paul said that it could also be in the Code of Conduct section because Members are required to read and agree with the Code of Conduct, which is also part of the Bylaws.
  • Dimitris said we can have this discussion further on the Public List to get more opinions from Members about the best location for this change.
  • Clint said he would write some of these up in GitHub and on the Public List.
  • Tim H. recommended that we look at the election rules, too.

Governance recap and IPR

Leader: Tim Hollebeek (Digicert)

  • Presentation link:* No presentation **Minutes:**Tim Callan (Sectigo)

Discussion outside the presentation

  • Tim Hollebeek: Governance reform is working pretty well. We used to just be one group and set of meetings. There were a few subcomittees active at any different time. The Validation subcommittee continues to exist. The motivation for these chagnes was to split out the Code Signing working group in its own bucket. Some people didn’t want to participate in the code signing BRs for IPR reasons. Now we have the ability to have each chartered working group separate with its own separate requirements. Now we have the same thing for the S/MIME working group. The Forum does not manage or coordinate between these working groups. These need to be IPR protected. The Forum is by-laws, logistics etc.
  • The NetSec Working Group is a working group that cross-cuts these other working groups. NetSec has a charter and scope that protects from IPR concerns. Even silent partiicpation in a working group still gives you IPR obligations.
  • Next steps: We were talking about a BRs working group for these cross-cutting initiatives. E.g. how do audits work, how do roots work? Clint proposed starting with definitions. This is a great place to start. We could start with a Definitions working ghroup that is very narrowly scoped.
  • Bruce Morton: If we had one working group that was cross-cutting, could these other items be subcommttees to that working group? We would need a lot of chairs and vice chairs with not enough people to do it. With subcommittes we could make requirements thinner and make expansion more agile.
  • Tim: That’s an interesting idea. There may be IPR concerns, but otherwise that’s a reasonable proposal. Let’s think about it.
  • Dimitris: I hear we’d be discussing less sensitive issues in the BRs working group. There are either IPR or non-IPR issues. In both my understanding and legal terms, I don’t believe there is some IPR or not. We will have to engage our legal teams every time we change guidelines, etc. So I think we’re in the same boat either way.
  • Tim: That’s a useful perspective. You’re right that IP is IP. But I meant to say issues that people are less likely to be concerned when joining a group with that discussion. We could have that problem and the more these cross-cutting working groups extend, the more of that trouble we will have.
  • Dimitris: If we go that route, the BRs WG with chartered subcommittes is probably the best route.
  • Tim: We could try to keep the IP to the subcommittees, where they have more leeway. We want to be concerned with the risk that if the scope of a BR is everything, we’re back to the old problem.
  • Dimitris: The main reason is that legal teams don’t want to review contributions for things they’re not engaged with. Writing this scope might be challenging, but maybe we can focus on definitinos and other common things wtihout any known IP issues.
  • Tim: We talked about starting wtih baby steps, and then we can deal with these IPR concerns as they come up.
  • Paul: If we’re concerned about IP issues discussed in this WG, this WG is intended to cover the other WGs anyway. So in the end the other WGs need to incorporate that anyway. So don’t we wind up in the same place?
  • Tim: The intent is that the BRs of BRs wouldn’t be automatically normative. It would be up to the free WGs to adopt or not adopt these suggestings depending on their needs. The WGs could choose to decline to take up these suggestions and they’d be insulated from that.
  • Paul: But the goal of the BR of BRs is to harmonize requirements. Is it really useful if we just cut things out at the WG level if we dont’ like it? Wouldn’t it be better to take it back to the BR WG and hash out something that does work everywhere?
  • Tim: If the WGs have feedback they can and should feed it back. There is great membership overlap, so communications problems should’t be an issue. We have that today where the Code Signing WG looks at the Server Certificate WG and has actually made suggestions that flowed back upstream. I don’t expect much trouble finding common ground on most issues. Most of the detail is the same for all certificate types.
  • Bruce: We have three WGs doing certificates with a lot of the same text. Maybe we can figure out what is the same. These other WGs can worry about what is the content of my cert, what is the profile going to be, etc.
  • Tim: It helps these WGs focus on what is important to them specifically. Identifying the scope of BR of BRs by looking at common text across documents is a great way to proceed.

Browser Updates

Mozilla Root Program Update

Leader: Ben Wilson (Mozilla)

Discussion outside the presentation

  • Jeremy: Are there plans to allow EdDSA for TLS certificate?
  • Ben: Not at this time, but that is something that we can discuss. For S/MIME, we plan to state that EdDSA (and ECDSA P-521) is allowed, but not supported by Mozilla products.
  • Martijn: Are you also considering to remove the “divisible by 8” for RSA key sizes?
  • Ben: I haven’t considered that, but we can discuss.
  • Aaron: The compliance self-assessment content are largely the same across root programs. What is the expected level of effort to leverage responses across Root Programs?
  • Ben: We are targeting a yearly cycle for submitting these assessments. We expect that a single self-assessment can be used for multiple Root Programs. We don’t want to create extra work unnecessarily. If we discover that we didn’t anticipate some scenario, please let us know.
  • Ryan: I agree with Ben’s response. The intent is never to create more work for CAs. We can align the submission cycle so that a single response can be used across Root Programs. Our expectation is that self-assessments are submitted at the same time audit reports are submitted. We plan to add alerting to CCADB for self-assessments.
  • Dimitris: I have a question about harmonizing TLS reason codes for TLS. We now have these requirements in the BRs. I think it may be clearest to point directly to the BRs.
  • Ben: That’s a good suggestion. If you have comments, please suggest on MDSP or add a comment on the Github issue.
  • Jeremy: One item to clarify is the timelines for externally operated subordinate CAs. Different timelines for audit submissions may mean that duplicate work is required for the self-assessments.
  • Ben: I understand the concern; complex PKI hierarchies complicate reporting.
  • Trev: If I understand Jeremy’s concern, it’s essentially a duplicate report. For SubCAs, the submission cadence may be different from the Root CA.
  • Ryan: For our policy, the submission cycle is based on the Root regardless of externally operated subCAs.
  • Bruce: Can we include the self-assessment requirement directly in the BRs? It sounds like there’s a desire to have consistent policies across Root Programs.
  • Ryan: The contents of the BRs are very relevant to this Forum. One challenge is that the self-assessment itself is not maintained by the Forum.

Google Root Program Update

Leader: Ryan Dickson (Google)

Discussion outside the presentation

Chris Clements provided an overview of Chrome root program updates. Latest version 1.4 effect Mar 3. 2023 was to align with CCADB and TLS BR. There is a “preflight process” of changes for the next version, shared as preview in order to solicit feedback before they become effective.

Version 1.5 SHALL include mandatory support for ACME for new applicants. It MAY specify requirements for types of certs that must be ACME-capable, URL disclosures in CCADB, endpoint capabilities and availability, support for RFC 8657, and support for ARI (ACME Renewal Information).

Chris reminded on Chrome policies for incident reporting. No need to notify Chrome if disclosed in Bugzilla. Incident reports must follow CCADB format and must:

  • Be accurate, detailed, timely, candid, and transparent
  • Demonstrate understanding of root cause
  • Demonstrate a substantive commitment that clearly and persuasively addresses the root cause

Chris provided a reminder of the “Moving Forward Together” paper which describes longer term initiatives that promote automation; modern infrastructure (such as term limits for roots, CAs and leafs); improved domain validation and multi point validation (MPV), and validation reuse, and simplicity (phase out of multipurpose roots). Seeking feedback.

The Chrome team is also interested in areas such as reducing missuance via linting and preparation for post-quantum crypto.

Chris gave a reminder of the “modern infrastructures” survey due June 9, appreciating the candid feedback from CAs. Feedback is always welcome at chrome-root-program [at] google.com.

Ryan Dickson spoke about Chrome’s motivation for pursuing increased automation, including agility (speed), resilience and reliability (eliminate human error, add scale, ARI to react to unforeseen events), and increased efficiency. Desire to move away from tracking and managing certificates using spreadsheets, forms, or home brew solutions. Chrome believes that automation reduces risk.

Ryan described why Chrome seeks to reduce validity, in part to drive adoption of automation, and to increase security.

Chrome stated a preference to move towards shorter validity for leaf certs (such as 90 days) but said they were seeking community feedback. Ryan said that security reasons for this include to reduce the maximum time a cert can persist for an unauthorized domain, and to reduce the maximum time a private key can be abused. Reduced validity will also lead to smaller CRLs with better latency, fewer timeouts, and lower costs. Wish to move to privacy preserving validity checking. He described an initial study performed by Chrome of CRLs disclosed to CCADB. Certs with validity greater than 90 days represent 43% of time-valid TLS server authentication certificates asserting a BR policy OID chaining to a root included in the Chrome Root Store, but represent 89% of TLS certificate revocations and 64% of key compromise revocations.

Jeremy Rowley of DigiCert pointed out that the weighting of these statistics are affected by Let’s Encrypt’s volumes and revocation practices. Jeremy also asked how more device makers could be attracted to support standards-based automation in their products as this was critical to enable movement towards shorter validity TLS.

Ryan described the CRL analysis relies on two assumptions: 1) CA owners are operating in conformance with RFC 5280 and the revocation date marked on CRLs is the actual date of revocation, and 2) that a snapshot in time analysis would not be meaningfully different than if a longer window was studied. Chrome studied CP/CPSs and determined revocation backdating did not appear a prevalent practice. Ryan described Andrew Ayer will be enhancing CRLWatch to better help study this issue by identifying when revoked certificate entries first appear on the CRL which will reduce reliance on a CA’s interpretation of revoction date. Ryan mentioned Chrome will continue studying the relationship between CRLs and reduced validity, and will share back findings. He encouraged others to also participate.

Paul van Brouwershaven pointed out that a study found that many platforms that implement the ACME protocol are tied to an individual CA, or do not allow revocation of certificates. He hoped that there could be a proactive forum to discuss these topics openly rather than as a response to a root program policy update. David Kluge welcomed speaking about the study of ACME implementation as that seemed to differ from Google’s research.

Ryan said reduced validity will reduce the impact of unexpected CT log retirements and help repair some of the problems in checking the validity of certs.

Ryan provided an update on CT policy. See slide. He noted a likely update to the Chrome CT Log Policy in the coming months focused on incident response. He noted two recent changes to CT log states.

Ryan provided PKI-related updates in upcoming releases of Chrome. See slide.

Wayne Thayer asked a question about the versions of Android in which the certificate verifier would appear. Ryan said these changes and the gradual rollout of the Chrome Root Store and Chrome Root Store are tied to the Version of Chrome and somewhat independent of Android operating system version, and said the Chrome team would provide additional information on these rollouts. A Google Chrome engineer mentioned that it should be supported on or after Android 7.0 Nougat where the latest Chrome application can be installed.

Apple Root Program Update

Leader: Clint Wilson (Apple)

Discussion outside the presentation

Today’s will serve as an update to the planned Apple policy release announced at the last Face-to-Face. Clint shared his appreciation for the community’s input on the proposed updates since F2F 58. A few changes to announce.

Planned effective dates (subject to slight changes based on discussions being led by Dimitris tomorrow)

  • August 15, 2023: Planned effective date for the updated policy
  • September 1, 2023: Expectation that S/MIME CA providers will be compliant with the S/MIME BRs (only applies to certificates issued on or after this date, though there is some dialogue happening within the S/MIME WG related to ICAs that don’t comply with the S/MIME BRs).
  • April 15, 2024: The time when Apple will only accept applications from single-purpose roots (as long as the application is open in CCADB before this date, your application will be considered). Apple has also updated Trust Bits for multi-purpose roots that only serve a single use case.
  • August 15, 2024: The time when CAs must support at least one of four validation methods described in the TLS-BRs. These are the most highly automated validation methods. CAs must support at least one of the prescribed methods; they are not required to support all four. Other existing validation methods may still be used. Based on Apple’s research, there are no known violations of the planned policy requirement.
  • December 1, 2024: Delivery date deadline of S/MIME audit reports.

S/MIME updates

  • Apple’s expectation is that CAs will be complying with the S/MIME BRs as of September 1, 2023.
  • Apple is concerned with transition of CAs that were operating without an established set of BRs to the post-S/MIME BR-era. Apple wants CAs to be proactive in seeking compliance with the S/MIME BRs. They would also like to see audit reports as soon as possible, balancing this desire with existing audit cadence to reduce off-cycle audits needs. By setting audit report delivery date by December 1, 2024, Apple believes the need for off-cycle audits can be eliminated.

Other Updates

  • Shifted away from auditor rotation. Auditor rotation will stay on Apple’s backlog, but prioritization will shift to clarifying requirements for auditor annual training. Apple received a great deal of support for formalizing annual training and corresponding requirements and expectations for auditors.
  • Firm and Auditor Qualifications will be updated to codify what appear to be existing conditions. The updates will focus on things like setting basic expectations such that firms are in good standing, appropriately registered, that signing and QA partners are appropriately credentialed, etc.

What’s next

  • A CA survey to collect feedback to confirm CA owner’s understanding of the changes described earlier in this presentation. Then, the policy will be updated and a communication will be sent to CAs confirming its publication. Note: This is the first survey feedback loop introduced by the Apple Root Program, your patience and feedback is appreciated.
  • Input on backlog – Apple would like your feedback on areas to prioritize or ways it can improve it’s policy (e.g., in a following version of our policy, we plan to add a change log).

No questions or added discussion.

Microsoft Root Program Update

Leader: Karina Sirota (Microsoft)

Discussion outside the presentation

Blake from Amazon asked why Microsoft Trusted Root Program are not supporting ECDSA. Karina responded that there is effort to evaluate other algorithms, but the team has de-prioritized ECDSA. There is no other information available about why ECDSA was de-prioritized.

Cisco Update

Leader: J-P Hamilton (Cisco)

Discussion outside the presentation

Various bundles of root certs in Cisco products (see slide). Cisco.com/security/pki contains the various list of roots.

CCADB Update

Leader: Clint Wilson (Apple, on behalf of the CCADB Steering Committee)

Discussion outside the presentation: No additional discussion.

ADJURNED Forum Plenary Meeting for Day 1

CABF Face-to-Face Meeting 59: Day 2 June 7, 2023

Attendance

Aaron Poulsen – (Amazon), Abhishek Bhat – (eMudhra), Adam Jones – (Microsoft), Adrian Mueller – (SwissSign), An Yin – (iTrusChina), Andreas Henschel – (D-TRUST), Aaron Poulsen – (Amazon), Aneta Wojtczak-Iwanicka – (Microsoft), Antti Backman – (Telia Company), Arno Fiedler – (ETSI), Ben Dewberry – (Keyfactor), Ben Wilson – (Mozilla), Brianca Martin – (Amazon), Bruce Morton – (Entrust), Chris Clements – (Google), Christophe Bonjean – (GlobalSign), Clint Wilson – (Apple), Corey Bonnell – (DigiCert), Corey Rasmussen – (OATI), Daryn Wright – (GoDaddy), Dave Chin – (CPA Canada/WebTrust), David Kluge – (Google), Dean Coclin – (DigiCert), Dimitris Zacharopoulos – (HARICA), Don Sheehy – (CPA Canada/WebTrust), Doug Beattie – (GlobalSign), Dustin Hollenback – (Microsoft), Ellie Lu – (TrustAsia Technologies, Inc.), Enrico Entschew – (D-TRUST), Eva van Steenberge – (GlobalSign), Fumi Yoneda – (Japan Registry Services), Georgy Sebastian – (Amazon Trust Services), Glaucia Young – (Microsoft), Hannah Sokol – (Microsoft), Hogeun Yoo – (NAVER Cloud), Hubert Chao – (Google), Ian McMillan – (Microsoft), Inaba Atsushi – (GlobalSign), Inigo Barreira – (Sectigo), J.P. Hamilton – (Cisco), Jamie Mackey – (US Federal PKI Management Authority), Janet Hines – (VikingCloud), Jeremy Rowley – (DigiCert), Joanna Fox – (TrustCor Systems), John Sarapata – (Google), Jonathan Kozolchyk – (Amazon Trust Services), Jos Purvis – (Fastly), Joseph Ramm – (OATI), JP Hamilton – (Cisco Systems), Karina Sirota – (Microsoft), Keshava Nagaraju – (eMudhra), Kiran Tummala – (Microsoft), Lakshmi Ramalingam – (Microsoft), Leo Grove – (SSL.com), Li-Chun Chen – (Chunghwa Telecom), Mads Henriksveen – (Buypass AS), Mahua Chaudrhi – (Microsoft), Marco Schambach – (IdenTrust), Mark Nelson – (IdenTrust), Martijn Katerbarg – (Sectigo), Matthias Wiedenhorst – (ACAB Council), Michael Guenther – (SwissSign), Michael Slaughter – (Amazon), Michelle Coon – (OATI), Mohit Kumar – (GlobalSign), Nargis Mannan – (VikingCloud), Nate Smith – (GoDaddy), Naveen Kumar – (eMudhra), Nick France – (Sectigo), Nicol So – (CommScope), Nitesh Bakliwal – (Microsoft), Pankaj Chawla – (eMudhra), Paul van Brouwershaven – (Entrust), Pekka Lahtiharju – (Telia Company), Peter Miskovic – (Disig), Raffaela Achermann – (SwissSign), Rebecca Kelley – (Apple), Roberto Quinones – (Intel), Rollin Yu – (TrustAsia Technologies, Inc.), Romain DELVAL – (Certigna), Ryan Dickson – (Google), Scott Rea – (eMudhra), Sissel Hoel – (Buypass AS), Stefan Kirch – (Telekom Security), Stephen Davidson – (DigiCert), Sven Rajala – (Keyfactor), Tadahiko Ito – (SECOM Trust Systems), Tahmina Ahmad – (Microsoft), Thomas Zermeno – (SSL.com), Tim Callan – (Sectigo), Tim Crawford – (CPA Canada/WebTrust), Tim Hollebeek – (DigiCert), Tobias Josefowitz – (Opera Software AS), Trevoli Ponds-White – (Amazon), Tsung-Min Kuo – (Chunghwa Telecom), Vijayakumar (Vijay) Manjunatha – (eMudhra), Vikas Khanna – (Microsoft), Wayne Thayer – (Fastly), Wendy Brown – (US Federal PKI Management Authority), Xiao Qiang – (GDCA), Xiu Lei – (GDCA), Yashwanth TM – (eMudhra), Yoshihiko Matsuo – (Japan Registry Services), Yoshiro Yoneya – (Japan Registry Services).

CA/Browser Forum Meeting

Bylaws updates part 2

Leader: Dimitris Zacharopoulos (HARICA)

Discussion outside the presentation

  • Question from Clint on release cycles. He doesn’t believe Proposal 1 solves the problems we’ve identified. If ballots are adopted at different points during the year and they’re collected only for March 15 or Sept. 15, then they are only grouped up in the BRs, which doesn’t help much, and the Emergency Guideline proposal doesn’t seem to resolve the problems because what would qualify as an emergency? He prefers something that allows effective dates more often – e.g., the 15th of odd months. Dimitris said he addresses other proposals more in line with Clint’s views in subsequent slides.
  • Dimitris believes that CAs will implement the changes as soon as a ballot passes. Most CAs change their CP or CPS at most twice a year. (They wouldn’t lay back and wait until Sept. 15th to implement changes.) The third point in Slide 3 (“Audit standards, auditor practices/guidance would be better prepared to audit the new requirements”) also applies to audit standards. The same applies to auditors. As soon as a ballot passes, auditors can start working on updating their audit criteria. The release of audit criteria would also be closer to the BR release dates. Dimitris agrees that an emergency process needs to be an easier process and quick and simple.
  • Clemens asked the source of need for these changes. ETSI perspective is that there isn’t a big issue. Whenever we start the audit of a CA or TSP, we grab the latest version of the Baseline Requirements, or whatever the current, latest standard may be, and use that. However, there may be ETSI auditors who don’t follow this pattern. If you have problems with CABs/auditors, let us know, and we’ll get back to them.
  • Dimitris said that time is needed for training, for example, when there is a new requirement for Multi-Perspective Domain Validation.
  • Clemens said first you need documentation. We cannot do an audit based just on a headline. For example, we have the S/MIME BRs, which we have had in hand for some time, and we’re ready to take that in an audit.
  • Dimitris argued that ability to audit new change does not happen momentarily or instantaneously.
  • Clemens said minor changes are not difficult, but major adoptions of requirements do take time.
  • Clint said inconsistency arises. He doesn’t see consistent behavior with implementation after ballots pass.
  • Dimitris says that WebTrust takes 2-3 months.
  • Trev asked whether we had resolved this before and wondered what we gain by putting this in the Bylaws. She also said that changes are going to happen during your audit cycle, no matter what we do.
  • Dimitris agreed, but said we need to see if we can find consensus on these issues until we can implement them in the Bylaws.
  • Don said that WebTrust has consistently grabbed everything through September and includes important things coming into effect, including sometimes things that pass in January and then publishes a new version in March. With this proposal, WebTrust would be updating its criteria twice a year. Under normal circumstances, the current process happens on a yearly basis.

Slide 4

  • Proposal 2 is the 15th of odd months (with no Emergecny Ballot provision). Tim H. said he now prefers even months – five even months, not including December.
  • Dimitris says that July or August should also be avoided.
  • Tim disagreed. If August 15th is rarely used, then that would be fine.
  • Dimitris would not want votes in opposition because it has a proposed effective date of August 15th.

Re: Emergency ballots under Proposal 3

Emergency Guidelines would be released bypassing the 6-month limit. A Ballot is declared an “Emergency Maintenance Guideline” by just having a proposer and two endorsers, without the need for a formal vote.

  • Dimitris asked whether the six-month cycle is feasible with an Emergency Guidelines provision available?
  • Clint and Ben prefer that it be more often than every 6 months – quarterly might be acceptable.
  • Bruce asked about established effective dates. Are we talking about publication/release dates or the effective dates fixed in the ballot?
  • Dimitris responded that the stated the effective date will be followed, but that minor formatting changes go into effect immediately on publication.
  • Bruce said that the publication/release dates don’t matter that much. Dimitris said that it is the effective dates that matter, regardless of when the guidelines are released.
  • Trev asked what we’ll be doing differently. We should either have two dates or not do anything to change the bylaws.
  • Clint said there is value on having some predictability on effective dates.
  • Trev said that it should be the third Monday of every other month.
  • Dimitris said we’re trying to avoid “freeze times” not certain days of the week.
  • Tim H. said that he picked the 15th – picking something is a step forward.
  • Trev said that timeframes can’t be too short. These dates are going to come up too soon.
  • Tim H. said that is another issue.

Proposed Changes to Server Cert WG Charter

Leader: Ben Wilson (Mozilla)

Discussion outside the presentation

Ben gave a brief review of the current SCWG Charter that is covered in the presentation slides. The update to the SCWG Charter originated from the ZT Browser ballot but it is not designed to address that specific issue but more broadly to improve the requirements for Browsers which are currently minimal.

Another idea was to promote more collaboration and contributions from Members. Members must attend at least 30% of SCWG Teleconferences in a 6-month period and at least one SCWG F2F meeting (physically or virtually) in any 12-month period to be considered as a Voting Member. There was some criticism about the lack of tooling to automate this measurement but the infrastructure SC will work on this. Each WG could have its own thresholds.

Dustin H. asked about the participation thresholds and noted that the F2F meetings are every 4 months. Ben clarified that there are two threholds for attending F2F meetings. The first one is for prospective voting members, that requires them to attend 1 F2F meeting over a 6-month period. The rationale was that we didn’t want to wait for 12 months to pass before considering a new member as a voting member.

Wayne mentioned that this proposal doesn’t sit well with him. He feels we should be as open as possible and this proposal is setting some obstacles. He understands the need for better criteria for Certificate Consumers, specifically operating a Root Store. Making it harder to become a member and to participate is the wrong direction. He also understands the concern around people hijacking the Forum but the Browsers can ultimately do whatever they want.

Wayne also added that as somewone who was involved in managing ballots in the past, this sounds like an administrative nightmare. He thinkgs that the 6 month probationary period is probably manageable but we should leave it at that.

Dimitris commented on Wayne’s position that Ben’s proposal doesn’t seem to forbid people from becoming members. They can join, participate, they can learn and contribute. The only thing that is removed from the current practice is the voting part. He also agrees on the administrative nightmare comments. We cannot enable this proposal without having the proper tooling in place and this is definitely a discussion we need to have at the Infrastructure Subcommittee.

Clint mentioned that he hopes this proposal will make participation easier as probationary, non-voting members but he does feel quote strongly that we should be protective of voting membership status, that is the ability to vote on standards that affect billions of people, and in very real ways. So having some protection and evidence that the votes are coming from folgs that are able to contribute positively is a nice goal, while at the same time open membership, open participation for everybody, contributing, talking in the forum, is also a goal that this proposal accomplishes pretty well.

Scott echoed what Wayne and Dimitris said about the administrative challenges and that this proposal would be great as long as we have the tooling to support it. Otherwise it will become and administrative nightmare.

Ben replied that perhaps we can carve out certain things but he still things we ought to have something that comes out of this proposal. He proposed continuing this discussion, gather more feedback, information and suggestions on how to improve this whole proposal.

Definitions and Glossary WG

Leader: Clint Wilson (Apple)

  • Minutes:* Clint Wilson (Apple)
  • Presentation link:* No presentation

Discussion outside the presentation

Tim H. volunteered to chair this CWG. Clint requested volunteers to vice-chair and stated that if there are no volunteers, Clint can do so. Clint reminded the Forum that the level of support and guidance from other members of the Forum is substantial, and newcomers to this type of role should not feel intimidated.

Brianca Martin and Tim Callan volunteered to vice-chair.

ATS Presentation on ICA rotation

Leader: Michael Slaughter (ATS) Trevoli Ponds-White (ATS)

Microsoft Cyber Defense: Helping to protect our customers and the Microsoft Cloud (Guest Speaker)

Guest Speaker: Aanchal Gupta (Microsoft)

  • Presentation link:* Not provided

Audit Updates

ETSI Update

Leader: Arno Fiedler (Vice Chair ETSI ESI)

Discussion outside the presentation

  • Arno gave an overview about the recent ETSI ESI activities, the discussions about support for QWACs and the Alignment of all trust services with NIS2 Directive Identity proofing.
  • He also reported about the new Work item for TSPs issuing publicly trusted S/MIME certificates that will be published for comments until End of June.
  • The next Day is planed for October 12th in Vienna

ACAB’C Update

Leader: Clemens Wanko (TÜV AUSTRIA)

Discussion outside the presentation: No additional discussion.

WebTrust Update

Leader: Tim Crawford, Don Sheehy, Dave Chin, (CPA Canada)

Discussion outside the presentation

  • WebTrust has created new audit criteria for NetSec (stand alone) and S/MIME BRs.
  • All other audit criteria have been updated with the exception of WebTrust for CA and WebTrust for RA.
  • WebTrust is also creating WebTrust for CA supporting X9 and WebTrust suporting IOT programs.
  • WebTrust is reviewing ISO 27099 to create new WebTrust for CA audit criteria. There are concerns as to how some criteria would be addressed for public CAs. There was also some pushback/concerns from CAs about using ISO 27099 as a new standard and pushing new policy. Does the policy apply?
  • It was suggested that although it is not a requirement, CAs should consider getting a point-in-time audit to the S/MIME BRs to ensure they are ready to issue and be prepared for their annual compliance audit.
  • CPA Canada has created new WebTrust Seals for S/MIME, NetSec, RA and a Qualified Audit. There was some discussion that there appear to be too many seals which use up a lot of real estate in the CAs repository or other web pages. It was asked is there a way reduce or combine the number of seals. This issue will be reviewed.

Summary Presentations from Working Groups

Server Certificate Working Group (SCWG)

Leader: Inigo Barreira (Sectigo)

Discussion outside the presentation: No additional discussion.

Code-Signing Certificate Working Group (CSCWG)

Leader: Bruce Morton (Entrust)

Discussion outside the presentation: No additional discussion.

S/MIME Certificate Working Group (SMCWG)

Leader: Stephen Davidson (DigiCert)

Discussion outside the presentation

  • New Certificate Issuer member: Logius PKIoverheid
  • Primary focus has been on answering questions arising from CAs implementing the S/MIME BRs.
  • Clarification-and-correction ballot is pending.
  • Release by DigiCert of PKILINT as OSS. Includes lints for the S/MIME BRs. https://github.com/digicert/pkilint
  • Externally: working with ETSI on TS 119 411-6 on implementation standard-mapping ETSI’s CPs with the S/MIME BRs. Draft will be available within 2 weeks.
  • This afternoon: discussion of ICA transition - existing or new ICA creation before effective date
  • After September 1: Topics relating Enterprise RAs; CAA; How to create bluesky between S/MIME and Signing?

Network Security Working Group

Leader: Clint Wilson (Apple)

Discussion outside the presentation

  • Vulnerability Detection and Patch Management
    • Ballot text drafted, informal discussion started
  • Air-Gapped CAs
    • Ballot text in-progress (near completion), discussion starting soon in CWG, also to be shared with Forum at large
  • No questions were asked about update

Forum Infrastructure Subcommittee

Leader: Jos Purvis (Fastly), Ben Wilson (Mozilla)

  • Minutes:* Wayne Thayer (Fastly)
  • Presentation link:* No presentation

Ben said that there is no update for this meeting. There were no questions.

ADJURNED Forum Plenary Meeting for Day 2

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