2025-10-15 Minutes of the Forum - F2F66
Minutes: Meeting was called to order by Dean Coclin (Chair). Representatives from the Certum welcomed everyone to Warsaw and gave some information about the facility and the evening event. Attendance was taken in the room and online. Minute takers were assigned for the day. Minutes from the prior teleconference were approved.
Guest Presentation: Andrea Rock, French Cybersecurity Agency
Challenges of automated issuance for QWACs and a possible approach
Guest Presentation: Alexandre Keck, CEO, GLEIF
[Trusted Identities for a Trusted Web: LEI and vLEI in the Digital Certificate Ecosystem](https://www.cabforum.org/uploads/2025/2025-10_OctoberF2F/2025-10-15_Trusted Identities for a Trusted Web_v2.2_draft-1.pdf)
CA Proposed Topics
Dossier (Corey Bonnell - DigiCert)
Minutes by Tim Callan, Sectigo Dossier, open source tool recently released by DigiCert Automated certificate report generation for Bugzilla
We can extract certificate information, for certificates involved in an incident, including extract relevant information
There is a command line tool, supports PEM and DER encoded certificate files, CSV, and ZIP
Open sourced from DigiCert. The slide deck contains links: https://www.cabforum.org/uploads/2025/2025-10_OctoberF2F/Dossier-1.pdf This is live now.
Reducing face to face meeting frequency
Minutes by Tim Callan
Clint Wilson proposes reducing the number of face to face meetings per year from three to two Clint feels we get most of the value from other sources such as GitHub, slide decks, mailing lists, and calls. Face to face helps coalesce discussion and move items forward. Shifting some focus to these other interactions would provide greater value.
Roman Fischer (Swissign) I agree. Including environmental impact and budget.
Scott Rae (eMudhra) Contrarian view. We were generally trying to focus on hosting the event in three geopolitical regions. I notice that here we are in the EU and we have a bunch of new faces. We might restrict some of that fresh blood.
Ryan Dickson (Chrome) It feels like we just gathered in Toronto. Many of the actions from that meeting haven’t seen much progress yet. It’s not clear how we will catch up. The more time between meetings will allow for that progress and collaboration. The weekly and biweekly calls are very productive. I recognize the time zones can be difficult.
It seems like we are struggling to come up with agenda items and topics. A lot of this could happen during regular working group meetings. We should welcome guest speakers to the regular meetings. These could be a regular part of our meetings. A large portion of these meetings seems to be recaps. This could be done in email. Let’s make the time here more useful and action oriented.
Chris Clements (Chrome) I notice we have started canceling the regularly scheduled calls the weeks prior to the face to face and now we’re cancelling the meetings following the face to face meetings. We’re losing other opportunities where we’ve had traction. The Forum has progressed a lot of things over the last couple of years and that’s due to us being effective in those regularly scheduled teleconferences.
Dean Coclin (DigiCert) What are your thoughts for when? Spring and fall?
Clint Wlison (Apple) Six months apart makes a lot of sense.
Brittany Randall (GoDaddy) If we keep a three meeting cadence, we could consider specializing for the different working groups. Maybe one meeting focuses on network security. Another focuses on server certificate.
Dimitris Zacharopoulos (HARICA) Some working groups might need to meet fewer times a year. Maybe some of them are two day meetings. I will present tomorrow the updates for the server certificate working group. Since the beginning of my participation in CABF, I have never seen a busier three month period. These meetings are an opportunity to regroup and get everyone organized. These aren’t as effective in the teleconferences.
Tadahiko Ito (SECOM) The face to face meetings are a great experience. It’s easier to meet here for the non-English native speakers. It would be great if more people come for face to face.
Dimitris Many times I have been approached by members who aren’t very vocal at the f2f meetings. The interaction between this community is important.
Karina Goodley (Microsoft) I’m in support of fewer meetings. Agenda should be the key driver. Just having discussions on what has been done. The validation summit years ago was a very good use of time. Topics that require in depth discussion, it’s beneficial to have a face to face. We have changed up the format.
Ben Wilson (Mozilla) If we go to two meetings, let’s analyze what the best parts of the F2F are and try to get that in the non-face to face environment.
Dean Some people are for moving things down. Some potential adjustments.
Clint: It sounds like there is some support for reducing the frequency. We definitely want to keep the value of F2F. I’m not sure where to take this next. Something like a straw poll makes sense.
Aaron Poulson (Amazon) Generally I’m in favor of reducing the number of meetings. We can make them longer if required. If we’re focusing on quality rather than quantity, I would like to extend this question to the weekly calls. We join the call and nothing has been done in the week prior. Are weekly meetings a requirement? Can they be bi-weekly or monthly instead?
Dean Aren’t most individual meetings bi-weekly?
Tobias Josefowitz (Opera) I suggest we try it and see what we think. We could try it and see what we think.
Steven Davidson (DigiCert) I would like to point out the variety of CAs present from around the world. I would like to encourage the browsers to come more often. A lot of momentum comes from the face to face meetings.
Miguel What matters isnt’ the number of face to face meetings but rather the value of them. Perhaps we can be more outcome based. Is there a goal in mind? Advocate for a more outcome based approach to both face to face and weekly calls.
Tim Hollobeek (DigiCert) The discussion has drifted toward how to get more done, not the number of meetings. I think there can be improvement to the face to face agendas. I think this has sucked a lot of value out of the agenda. It was a smaller group 5 or 10 years ago,which make it more productive. But there could be a discussion of a topic. They were more of a deep dive. Validation summit was useful and there should be more like that. There are so many working groups that things get covered at a surface level. The benefits of the side conversations are real, and losing that would be unfortunate. I have had problems with some of the calls as well. Many working groups have fallen into that trap. More productive agendas is the right goal.
Ryan One of the key challenges we have is that this work is not super predictable. It’s difficult to predict what we need to discuss in 6 or 9 months. One way to make this more predictable is about better sharing our ideas. The presentation we’re giving tomorrow is something we ‘ve been thinking about for a while.
Miguel I understand things can be unpredictable. I think getting together is useful. On the weekly calls there are usually the same 3 or 4 people talking. How do we get those people talking. I think we can get more engagement if you set the agenda correctly.
Clint I did look back to face to face minutes going back years. The people talking on the weekly calls are the same as people in the F2F minutes Side conversations are another matter.
Miguel It’s also because it’s the way it’s set up. IF we had breakout rooms it would have a different vibe than auditorium style.
Dean We tried to do breakouts a few years ago, but people wanted to be in both of them.
Karina We could have forcing functions in other ways. Could we have standardized times for different CAs to present something. If you know you’re presenting at this meeting, you will find something to discuss.
Dean We started the CA-proposed topics at the last meeting. Maybe we find CAs that want to present.
Karina I love the guest speakers. We can also have CA topics in the weekly meetings.
Miguel If you have an objective to modernize the netsec requirements, let’s say, if you focus on just that for three days. It’s a workshop. At the end you have a finished result.
Dean We did that with code signing. We had a workshop. We can do something similar with these other topics. We drifted away from the main topic, which was going down from 3 to 2x. Let’s take a straw poll for who
Scott Rae It’s much easier to cancel one to add one if we start doing ad hoc meetings. I would like to have three on the agenda and we can cut
Karolina Ruszczynska (Certum by Asseco) If we want to reduce the number of meetings, why.? Is it only the money and time , or are we concerned about their usefulness and purpose?
Mozilla Root Program Update
Minutes by Dimitris Zacharopoulos, HARICA
Ben plans to discuss the Revocation reason codes during the server certificate WG meeting tomorrow.
Mozilla is considering hard or soft-failing based on the revocation reason code.
Perhaps reduce the number of reason codes used in the TBRs? Something to consider/discuss.
Rob: Is there an official CT Policy? Is there a CT log operator policy?
Ben: There will be an official CT policy, there is only a reference within a wiki page. The plan is to have a separate document and link it to that wiki page
Miguel: Is there a plan to create a ballot to update the reason codes or is this within the MRSP? Ben: The intent is to introduce a ballot within the CABF. The proposal will be discussed in the SCWG.
[Not sure who asked this???]: Is it necessary to request the inclusion of an RSA and an ECC Root?
Ben: It’s up to the CA to decide. Most importantly, CAs need to prepare for Post-Quantum Roots.
Apple Root Program Update
Minutes by Martijn Katerbarg
Presented by Clint Wilson and Dustin Hollenback
Staffing Update: Root Program Lead role will transition from Clint to Dustin Clint will stay around and will remain chain of NetSec Root Inclusion Requests pending, processing these is priority right now. Apple Root Program Policy Update is being started now.
Aaron: When is the policy update expected to land? Dustin: It’s planned for Q4, but currently no date set.
Chrome Root Program Update
Minutes by Aaron Poulsen
[Presentation](https://www.cabforum.org/uploads/2025/2025-10_OctoberF2F/CABF F2F 66 Chrome Browser Update [PUBLIC].pdf)
Ryan Dickson
Discussion outside the presentation:
Ryan | Chrome: Technical enforcement of reduced certificate lifetimes will go into effect in March. Chrome will begin enforcing the 200 day certificate validity.
Nick | Sectigo: How are CO CA owners defined? I know there’s a field in CCADB, but what about CAs that are listed as separate owners but are legally the same ownership?
Ryan | Chrome: We consider legal ownership the same. We define CA Owner in our policy. Using Sectigo as an example, the various brands (Comodo, AAA) - they are all considered Sectigo since they operate under the same legal ownership. We can clarify that during the (Chrome) policy pre-flight process.
Roman | SwissSign: Can you say anything about your backlog of route inclusion requests?
Ryan | Chrome: Our backlog is not that significant. We’re aggressively trying to wrap them up. Current queue is around 4. Our first step is doing a preliminary check - we call it a completeness check. We do a quick scan to make sure the expected requirements or expected artifacts are provided. Around 75% of cases received the submissions are incomplete or do not meet policy expectations. We try our best to inform CA owners of problems earlier in the process rather than later. You’re free to email us any time as is any other CA owner looking for an update.
Dean | DigiCert: I noticed you said several times about benefits to a majority of Chrome users for including roots. What if you have a new CA with NO history just starting up - how do you gauge that in terms of benefiting Chrome users?
Ryan | Chrome: CA owners are expected to complete a form when they apply. Responses give us insight regarding operational practices and we partly derive the perceived value to Chrome and the (WebPKI) ecosystem (from these responses). It’s why we find value in practice statements and PKI policies. One of many reasons why we find those documents valuable. We also list things that are considered favorable on our “Apply for inclusion page”. We also have moving forward together, which is our long term roadmap, so looking for things that we publicly list already are good signals for new CAs.
Dimitris | Harica: Going back to the observation about the number of roots that can be included in the root store. Your telemetry shows that some CAs do not issue new certificates - how can you be sure if they aren’t being used in TLS connections with other browsers? CAs can sometimes keep the older roots for ubiquity reasons.
Ryan | Chrome: We have no telemetry for other browsers. Our decisions are specific for Chrome users and Chrome user security. If we see a root that hasn’t been used in user connections in Chrome: that’s an indicator. And it is not providing any value for our users. And in many cases these are older CAs that have already issued cross-certificates to newer roots and Chrome will prefer the shorter path. There’s really NO world where that old root would be used by a modern Chrome client unless a Chrome user explicitly distrusted the newer self-signed certificate (which wouldn’t really make sense). Also if we’re thinking about the concern with older clients, older clients wouldn’t be aware of the updates that are being made to remove those old roots, so they’re like frozen in a point of time.
Dimitris | Harica: Thanks.
Tadahiko | SECOM: I have two questions. What happens if a CA operator exceeds the number of roots? Also wondering about the extent automation support (must be enforced) for new applicants and does it apply to each hierarchy or each intermediate?
Ryan | Chrome: (For the first question): yes, we do clarify that the policy does allow for transitions. Assuming that SECOM has two routes in the Chrome root store and they would like to apply with two new roots because they’d like to move forward with a modern hierarchy; we would add your new root with the expectation that your old roots would be phased out. So all leafs chaining to those old roots would eventually expire, and at that point in time they’d be removed from the root store and then all issuance from that point forward would be from the new CAs. That scenario is described in the policy.
Aaron | Amazon Trust Services: Do you have, at this point, or can you disclose your thoughts on the limits for roots or the criteria that you would use in determining how many roots a CA owner can have in your root store?
Ryan | Chrome: We’re essentially debating between two or four as the maximum number. When we ran the numbers only ~15% of CA owners in the Chrome root store exceeded the threshold that we had set. If a root is really just a trust anchor, which is really just a public key, it’s not clear why there needs to be so many roots. We see most CA owners in the Chrome root store today having two or less. That seems to function totally fine. If there’s a compelling reason why more are needed we hope to get that feedback during the pre-flight process. We’re always happy to consider that feedback. Our main priority at this point is reducing the attack surface and removing complexity.
Dean | DigiCert: I don’t know if you’ve been hearing from customers around your planned deprecation of mTLS. We’re getting an ear-full from people. Have you heard things and what are you telling them?
Ryan | Chrome: Yeah, we engaged with a customer just yesterday. It seems like there’s a lot of not quite accurate information on the deprecation of client auth. Our policy is specific to the roots included in the Chrome root store. Our policy does not prohibit CA owners from supporting client auth use cases. Digicert has X9. Our policies do not apply to X9. X9 could be a perfect point of transition for existing DigiCert customers. We’re aware of other CA owners offering similar functionalities. We still believe that client off is a use case best served from the private PKI hierarchy. We also encourage the CABF and we would support a client auth working group or adding explicit profiles or or some other solution to the BRs that would allow these certificates still to be trusted by the consumers that rely upon them.
Microsoft Root Program Update
Minutes by Corey Bonnell
[Presentation](https://www.cabforum.org/uploads/2025/2025-10_OctoberF2F/Microsoft F2F 66 Presentation.pdf)
Karina Goodley
Discussion outside the presentation:
Tim H: Like composite, the ML-DSA-87 in X.509 specification is also not complete at IETF. I agree that it is ready for the pilot program.
Karina: Yes, and the pilot details have not yet been finalized.
Rob: Will you have a CT policy in time for the mandatory logging requirement?
Karina: We will clarify.
Dimitris: Having to update the CP/CPS documents within 7 days is challenging for CAs that maintain documentation in multiple languages.
Martijn: You could wait to put changes into effect until they are published. The documents are supposed to be a reflection of current practice.
Aaron P: Policy updates go through a PMA for approval. It is difficult to have that happen on a short timeframe. It adds a burden for something that is critical to CA operations. What was the motivation behind choosing 7 days?
Karina: We can be flexible in the policy, but we do expect timely updates.
Roman: Do we have to publish updates for every standards update, even if the change isn’t relevant to CA operations?
Karina: The intent is that actual practices are reflected in the documents.
Dimitris: The intent is to not create burden, but I believe the proposed policy language does not align with the intent.
Karina: We can adjust the proposed policy language to align.
Tadahiko: What are the requirements to join the PQC pilot? Are there additional profile requirements, such as policy OIDs?
Karina: Because it is a pilot program, there are no audit requirements. Additionally, there are no policy updates needed.
Aaron P: Thank you for numbering the requirements.
Stephen: The only CA/B Forum profile with PQC support is S/MIME. Are there any plans for an S/MIME PQC pilot?
Karina: It is currently not in scope for the pilot.
Inigo: Which in OID should be included for MSFT Office document signing?
Karina: I’ll review to ensure it is listed.
Hamdi: You previously stated that you are not accepting new CA (organization) inclusion requests, is that still correct?
Karina: Yes
CCADB Update
Minutes by Tobias Josefowitz
[Presentation](https://www.cabforum.org/uploads/2025/2025-10_OctoberF2F/CAB F2F 66 CCADB Update [PUBLIC].pdf)
Chris presented on behalf of the CCADB SC.
The presentation comprehensively contains the full update, no questions were asked from the audience.
Q&A Root program discussions
Minutes by Kateryna Aleksieieva
Summary
The discussion focused on differing Root Store positions regarding support for Client Authentication (mTLS) certificates under public TLS hierarchies. Participants noted that while some Root Stores plan to deprecate ClientAuth, others may continue to support it, creating uncertainty for CAs. It was observed that most mTLS use occurs in server-to-server environments relying on the Mozilla Root Store (NSS), rather than within browsers. Microsoft clarified that ClientAuth remains supported at the platform level but not in Edge, which follows Chromium policy. Participants agreed that most mTLS cases involve legacy setups reusing the same certificate for both TLS and client authentication, and that updating these systems will be challenging but may eventually be required.
Dimitris (HARICA) started by saying that after hearing the Chrome and Microsoft presentations, he is unsure how to handle the conflicting positions on Client Authentication. One Root Store is moving to deprecate ClientAuth, while another may continue to support it under the same TLS hierarchies, and he is trying to find ways to avoid problems caused by this difference.
Martijn (Sectigo) said that the answer should be that ClientAuth cannot use the same hierarchies as TLS.
Dimitris replied that for mTLS to work, the same hierarchy is usually needed.
Martijn responded that while some implementations depend on that setup, they can be changed. He pointed out that most mTLS cases are server-to-server and do not use Microsoft or Chrome Root Stores. Instead, they often depend on the Mozilla Root Store (NSS), which is part of nearly all Linux distributions and much embedded firmware that cannot be updated easily.
Dimitris noted that CAs which have requested distrust of a root included in both Mozilla and Microsoft Root Stores could now face trouble because of this.
Karina (Microsoft) asked what the specific concerns were and whether there are browser use cases that actually require mTLS. She explained that the Microsoft platform still supports ClientAuth, but the Edge browser does not, because it follows Chromium. The operating system is separate and continues to allow it. She said it would help to have clear examples where things start to break so that Microsoft can look for solutions.
Dimitris said that most mTLS use cases rely on common trust stores, such as NSS, and agreed to review and share examples.
Karina encouraged everyone to send specific examples to help understand the problem and possible fixes.
Tobias Josefowitz (Opera) asked whether there are any real browser use cases for mTLS with publicly trusted certificates. He said it seems unlikely that a user would get a publicly trusted client certificate from a Web PKI CA, load it into a browser, and use it to log in to a website. He added that most uses of mTLS borrow from Web PKI but are not truly browser-based. Toby suggested treating these as two separate cases: (1) applications that depend on Web PKI, and (2) in-browser use, which does not seem to happen.
Karina agreed and said the more examples they can collect, the better.
Dimitris replied that in most cases the same certificate is used both for the web server and for client authentication. These are usually older systems that will need to be changed, as Martijn mentioned. He said such changes will be difficult, and while using two separate certificates might make sense, it is not clear what the real security benefit is compared to the extra burden on those managing these systems.
ETSI Update (Arno Fiedler, ETSI/ESI Vice Chair)
Arno updated on the state of play in the ETSI/CEN norms development, especially keeping effects of eIDAS2, NIS2 and other legislative requirements in Europe in consideration. Furthermore, he interfaced with his background explanations into the framing developments around the EU Digital Identity Wallet (EUDIW), laying down corresponding new fields of play for CA /QTSP.
ACAB’c Update (Clemens Wanko, ACAB’C/TÜV AUSTRIA)
Clemens explained the relevant legislation for audit requirements: eIDAS and NIS2 and laid down the importance for (EU based) CA/QTSP to show compliance. NIS2 defines TSP as an important entity and QTSP as an essential entity. Branch-specific requirements are defined by DORA and CRA. Clemens encouraged the use of the latest Audit Attestation Letter Template, which can be downloaded from acab-c.com.
WebTrust Update
Web Trust Update – Minutes from F2F Warsaw 15 Oct, 2025 [Presentation link](https://www.cabforum.org/uploads/2025/2025-10_OctoberF2F/Webtrust - CABF Warsaw 66 FINAL October 2025.pptx) Session led by Lilia Dubko & Tim Crawford Lilia reported on the promised updates to the WebTrust Task Force as identified in the prior F2F in Canada. WT recognized at that time the need to expand the web trust task force to ensure that the necessary manpower and diversity of perspectives were available to effectively tackle new projects and initiatives. The outcome is broader representation from various geographical regions and firms to bring together a broad range of expertise. The new TF started operating in the summer, first met in September and consists of the following:
- Lilia Dubko, [CPA Canada] (Co-Chair)
- Tim Crawford, [BDO] (Co-Chair)
- Chris Czajczyc, [Deloitte]
- Eric Lin, [EY]
- Adam Flock, [BDO]
- Masatoshi Shigaki, [KPMG]
- Zain Shabbir, [KPMG]
- David Lachmansingh, [Richter LLP]
- Jinhwah Shin, [Deloitte]
- Jeff Ward, [Aprio LLP]
- Brian Hsiung, [SunRise CPAs]
- Peter Mate Erdosi, [Crowe] TF focus for summer was to publish some updated documents e.g. ISAE 3000, CSAE 3000, AICPA. Current work planned includes updates to WebTrust for NSRs, WebTrust for TLS BRs, WebTrust for RAs, and carve-outs on subservice examples. Remote Signing and Practitioner guidance is planned for further in the future (next year). Tim detailed the set of updated Reporting Templates that have been produced i.e.
- Templates for reporting NSRs and TLS BRs separately
- Inclusive subservice provider examples
- Management assertion by service provider
- Qualified seal updates
- Updated Canadian and International reports for transitional issues
- Joint US and International reports
- Other cleanup & minor updates Two additional guidance reports should be released within the month:
- Updates to WebTrust for RA
- Examples of Carve Out report (not really relevant to CABF) Updates to WebTrust Criteria (normally done in spring) will be produced in an out of cycle manner to address the Mass Revocation requirements. Some additional reporting guidance is planned to be released in Nov 2025:
- Reporting locations (include all locations, indicate applicable cloud regions, indicate if physical controls were tested)
- Clarify reporting CP/CPS version in-scope
- Standardize guidance on commenting on considerations of root causes and actions to remediate identified in any bugs Other projects the TF is working on outside Web PKI:
- Individual Identity Vetting
- Signing Services e.g. Doc Sign – some initial conversations with Adobe on requirements
Q&A Audits and Standards (Panel)
Minutes by Tim Callan, Sectigo
… No questions.