Meeting 60 minutes

CABF Face-to-Face Meeting 60: Day 1 October 3, 2023

CA/Browser Forum level Meeting

Attendance

Aaron Gable – (Let’s Encrypt), Aaron Poulsen – (Amazon), Abhishek Bhat – (eMudhra), Adam Jones – (Microsoft), Adrian Mueller – (SwissSign), Adriano Santoni – (Actalis S.p.A.), Aleksandra Kurosz (Asseco Data Systems S.A.), Andrea Holland – (VikingCloud), Andreas Henschel (D-Trust), Aneta Wojtczak-Iwanicka – (Microsoft), Anna-Marie Christian (WebTrust / CPA Canada), Antti Backman – (Telia Company), Arno Fiedler – (ETSI), Arnold Essing (Telekom Security), Arvid Vermote – (GlobalSign), Ben Wilson – (Mozilla), Brianca Martin – (Amazon), Brittany Randall – (GoDaddy), Bruce Morton – (Entrust), Chris Clements – (Google), Christophe Bonjean – (GlobalSign), Clemens Wanko – (ACAB’c / TUV Austria), Clint Wilson – (Apple), Corey Bonnell – (DigiCert), Corey Bonnell (DigiCert), Corey Rasmussen – (OATI), Daryn Wright – (GoDaddy), Dave Chin – (CPA Canada/WebTrust), Dean Coclin (DigiCert), Dimitris Zacharopoulos – (HARICA), Don Sheehy (WebTrust), Doug Beattie – (GlobalSign), Ellie Lu – (TrustAsia Technologies Inc.), Enrico Entschew (D-Trust), Eva Vansteenberge – (GlobalSign), Hannah Sokol – (Microsoft), Hogeun Yoo – (NAVER Cloud), Ian McMillan – (Microsoft), Inaba Atsushi – (GlobalSign), Inigo Barreira – (Sectigo), Janet Hines – (VikingCloud), Jeremy Rowley – (DigiCert), Joanna Fox – (TrustCor Systems), Jochem van den Berge – (Logius PKIoverheid), John Mason (Microsoft), John Sarapata (Google Trust Services), Joseph Ramm – (OATI), Jozef Nigut – (Disig), Kateryna Aleksieieva – (Asseco Data Systems SA (Certum)), Keshava Nagaraju – (eMudhra), Kiran Tummala – (Microsoft), Leo Grove (SSL.com), Li-Chun Chen (ChungHwa Telecom), Lynn Jeun – (Visa), Mads Henriksveen – (Buypass AS), Marcelo Silva – (Visa), Marco Schambach – (IdenTrust), Martijn Katerbarg – (Sectigo), Michael Guenther – (SwissSign), Michael Slaughter – (Amazon), Michelle Coon – (OATI), Mohit Kumar (GlobalSign), Nargis Mannan – (VikingCloud), Nate Smith – (GoDaddy), Naveen Kumar – (eMudhra), Nicol So – (CommScope), Nikolaos Soumelidis (QMSCERT), Nitesh Bakliwal (Microsoft), Paul van Brouwershaven – (Entrust), Pedro Fuentes – (OISTE Foundation), Pekka Lahtiharju – (Telia Company), Raffaela Achermann – (SwissSign), Rebecca Kelley – (Apple), Rich Kapushinski – (CommScope), Rob Brand (Ministry of Economic Affairs and climate Policy (NL)), Rob Stradling – (Sectigo), Rollin Yu – (TrustAsia Technologies Inc.), Roman Fischer (SwissSign AG), Ryan Dickson – (Google), Scott Rea – (eMudhra), Sissel Hoel – (Buypass AS), Stephen Davidson – (DigiCert), Steven Deitte – (GoDaddy), Sven Rajala – (Keyfactor), Tadahiko Ito – (SECOM Trust Systems), Tim Callan (Sectigo), Tim Crawford – (CPA Canada/WebTrust), Tim Hollebeek (DigiCert), Tobias Josefowitz – (Opera Software AS), Tom Zermeno (SSL.com), Trevoli Ponds-White – (Amazon), Tsung-Min Kuo – (Chunghwa Telecom), Vijayakumar (Vijay) Manjunatha – (eMudhra), Wayne Thayer – (Fastly), Wen-Chun Yang (ChungHwa Telecom), Wendy Brown – (US Federal PKI Management Authority), Xiu Lei – (GDCA).

Approval of CABF Minutes from last teleconference

Leader: Dimitris Zacharopoulos (HARICA)

Minutes were approved.

Future face to face meeting schedule

Leader: Dimitris Zacharopoulos (HARICA)
Presentation link: /uploads/1-CABF_Future-meetings.pdf

• Spring 2024 meeting will be hosted by eMudhra in New Delhi, India
• Summer 2024 meeting will be hosted by Actalis in Bergamo, Italy
• Fall 2024 meeting will be hosted by Amazon in Seattle, WA

Discussion outside the presentation: No further discussion.

Forum Infrastructure Subcommittee

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

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

Discussion minutes:

Jos Purvis (Fastly):

Jos thanks the guest speaker for being flexible in schedule.

Jos raises the question for how the Wiki is going for everyone.

Paul van Brouwershaven (Entrust):

When we first previewed the wiki, it was very well organized. But now in production I’m having trouble finding things.

We also tend to find earlier drafts and I don’t know if this is real work or something that is being accidentally drafted.

Jos:

I have gotten that impression as well. It has been bumpier than we thought. Some aspects got better but other things got harder.

Dimitris Zacharopoulos (Harica):

I’m also having some difficulty finding things. I’m also having trouble understanding the terminology and structure of the new wiki. Perhaps some instructions for working group chairs, etc. might be helpful.

For today I wanted to add a page for the minutes, and I didn’t know if I should create a page or put it under another page or what.

Jos:

Each particular wiki is opinionated about how it thinks your info should be laid out. In the initial evalatation, the sructure seemed to make sense, but the more we have rearranged, we are running into friction with how it thinks it should be laid out. If it’s creating more work than it’s solving, then it’s not a helpful tool.

I would rather back up a step and consider a different tool than trying to adjust everyone’s thinking to a different way of laying out information. I think maybe this hasn’t been the right tool.

Dimitris:

Maybe it’s not the tool. Maybe people don’t know how to organize and use it.

Clint Wilson (Apple):

Overall it’s a lot easier to actually work in the editor. The main issue I have is finding stuff that was in the old wiki. But maybe it’s more about documentation of the wiki and how to use it and structure it. Not as far as a style guide, but something to help.

Paul:

Looking at meetings, there are 142 pages in Records. When I go to face to face meetings, it sends me to face to face meetings calendar. It seems like we have a tree structure in the left, but it seems like w’re missing some information there. and we have a tree structure at the top that doesn’t make sense.

Perhaps the template could really be a template.

Maybe the tool is fine but we put some effort into organization.

Jos:

In the course of moving things over, maybe stuff got garbled. It’s very difficult for the old archival information not to come up in a search. If we would find it useful, Iw ould be happy to write up a quick summary of how we think about information. I think that’s a good idea. We tried to dump everytihng to the wiki. That didn’ work well. so maybe we start with a clean wiki with no info in it and turn it over to the committee chairs to organization as they see fit. Migrate content, and create new content as they see fit.

Aaron Poulsen (Amazon):

I would love to see some consistency in the wiki. I have found navigation convoluted with the new wiki to the ponit where I no longer come to the wiki for information.

Jos:

That’s what we want to avoid.

Trevoli Ponds-White (Amazon):

Something I always want on the wiki is a landing page for the groups. When I left, I wanted to send messages to chairs of the groups, and we didn’t have basic stuff for most of the working groups on the wiki with the relevant informaiton for that WG.

Jos:

I will commit next meeting to talking about how the wiki tihnks about information. Let’s use that as a starting poing.

Trev:

I wouldn’t purge all the content just because it’s hard to navigate.

Jos:

I will pull somethign together about what it can do and how it thinks about information so we can make better decisions.

Aaron Gable:

Two additional comments.

I think we’re in a situation where for any given item of information there’s a lack of clarity for if it’s true home is the wiki or the website. Server Certificiate Working group has pages for every ballot. Is the page on the wiki or the website the authoritiative source for that ballot? Why do we have both? We should clarify things like that.

We have a habit of not cross linking very much. Cross linking (and our emails) don’t do that very much. Like there was a recent email saying the agenda has been updated, but there was no link to the meeting 60 agenda page in the wiki. There is a culture change we can make about using links, which would make navigation much easier.

Jos:

I very much agree with the information heirarchy problem between the wiki, the website, and GitHub. Where do I create things? We could use a step back to think about what we want our information flow to be. It’s okay to say we’re going to do this function at only one place and not anywhere else.

Paul:

We heard a few sources about where ballots can be located and also recording votes etc. It would be valuable if we more formally used the pull request to actually hold the ballot language and could have approvals of code owners assigned to that.

Aaron P:

Jos, this isn’t easy so we really appreciate you and the team working on this.

Jos:

We may also come back with a suggestion for what we think the information flow and heirarchy should be, to consider. This is exactly the kind of feedback I was hoping to get today. Please contact me or the infrastructure subcommittee if you have any more input.

Other pieces on the project list include:

• Wayne was working on some of the issues with email bouncing. We need some adjustments to our setup.

Ben:

We don’t have anything structural on web site changes.

Jos:

Onboarding instructions were a significant project that we want some movement around. It’s a documenting-how-things-work project that is on our slate for this next term.

Is there any other new business to discuss?

(No new business is raised.)

Dimitris:

Thanks to the infrastructure subcommittee for doing such great work and keeping things running.

Open Mic

Discussion leader: Dimitris Zacharopoulos (HARICA)

Minutes: Dimitris Zacharopoulos (HARICA) & Kiran Tummala (Microsoft)

(Paul): The CABF is usually re-active. We are missing the pro-active work. We usually do not engage in controversial topics where we should be discussing what is making a topic controversial. Try to set goals and what needs to be accomplished. Make documents more readable.

Clint asked for a specific example

Paul mentioned that it would be more efficient to if the forum would evaluate for example the objective for proposing somthing such as the Google’s 90-days cert validity proposal as a collaborative effort, instead something that is driven outside the forum. By collaboratively looking at the issue (instead of the solution) we create a better perspective, look at different mitigations, and create broader support from the members.

Another example given by Paul is Post-Quantum. How is the forum going to prepare for PQC, are we going to endorse hybrid/composite certificates? What quantum-resistant algorithms do we select for TLS, SMIME, or CodeSigning, certificates, these might not be the same because of the different use case and algorithm characteristics. What about the size of the certificates and Root Stores now we also move to single purpose hierarchies, root stores are going to become significantly larger. The impact of SCT signatures, etc. While for TLS the harvest now, decrypt later attack can be mostly addressed in the TLS session key-exchange (i.e., PFS), this does not protect the client/server authentication.

Paul also mentioned about the compliance risks and audit costs when there are standards with similar requirements, similar language with different titles.

Trev: Sometimes we can present problems and solutions and data to support that.

Paul said we should present issues with concrete data, even without a solution, and let the Forum propose solutions. We should always talk about the problem we’re trying to resolve.

Tim Callan: What you get out of it is what you put in it. Members need to bring in more issues and drive them. If it’s a reasonable issue, it will be discussed and proposals will be presented.

Trev: We need a higher-bar for the presentations. Dig into the data behind it and then make policy changes. We see many bugs on a certain issue that can drive policy changes.

Nitesh: Driving with focus on objectives with data backing is critical, v/s jumping to solutions directly. Another aspect that forum should consider is to publish each year ahead goals/objectives for each sub-workstream, to drive future looking aspects more predictably

Dimitris: If a Member has an issue that wants to be discussed but doesn’t have time to drive it, the issue should be shared with the larger group because there might be others that face the same issue, and perhaps another person can drive it.

Share lessons learned from CAs and continuous improvement. Presentation from ATS with important lessons learned. Share these initiatives more broadly. Codifying these implementations in the BRs later.

Paul: Should we make the recordings available because of the different geographical locations of our members?

Perhaps share on the Management List, don’t share, don’t store it.

Start with a slide with the Notewell, you are not suppored to make this public.

Archival bit, after some specific times.

Clint: Add the recording and transcript to the member’s tool for a certain amount of time.

Agree to stop the recording when there is a confidential issue to discuss. That topic will not be added in the minutes.

Put on the Agenda at the next F2F Teleconferences for action items.

Guest Speaker

Presenter: Rob Brand – Ministry of Economic Affairs and climate Policy (NL)

• Title:* Building Trust, Empowering the Digital Economy – eIDAS Trust Services
• Presentation link:* /uploads/2-Guest-Speaker-231003CABForum-Presentation-NL-v1.0.pdf
• Minutes:* Kiran Tummala (Microsoft)

Presentation Notes:

Management Audit and Certification Process in the Netherlands

• Rob discussed a management audit that was conducted in the Netherlands regarding the certification process for trust services.
• It was noted that the supervisory body in the Netherlands did not have the authority to provide a second opinion on the certification process.
• The process seemed less robust, leading to concerns about the quality of trust services certification in the past.

Telecommunications and Digital Hack in 2011

• Rob highlighted that the supervisory body’s limited knowledge in the telecommunications sector contributed to a significant digital hack in 2011.
• A man-in-the-middle attack with fake certificates exposed weak security practices.
• The impact was significant, affecting qualified certificates and leading to the shutdown of government services.
• A certification authority even went bankrupt.

Security Awareness and Regulatory Adjustments

• After the 2011 incident, the Netherlands took steps to increase security awareness.
• Efforts were made to adjust regulations within Europe regarding certificates.
• Three key areas of improvement were identified: increased security awareness, legal improvements, and organizational measures.

Role of the Inspector for Digital Infrastructure

• A new supervisory body, known as the Inspector for Digital Infrastructure, was established in the Netherlands.
• This body took on supervisory tasks and aimed to become a knowledge center for trust services.
• This development was considered a positive step in improving oversight.

Yearly Crisis Exercises and Multi-Vendor Strategy

• The Netherlands initiated yearly crisis exercises and developed a crisis manual for digital affairs.
• A multi-vendor strategy was implemented to avoid dependency on a single organization in case of a disaster.
• This strategy aimed to ensure continued government operation in the event of a similar crisis.

Impact of eIDAS Regulation

• The eIDAS regulation was hailed as a dramatic improvement over the previous signature directive.
• It harmonized requirements and introduced product certification based on standard 1765.
• Auditors could now assess systems directly, not just the management system.

Supervisory Body Independence

• The eIDAS regulation gave supervisory bodies the autonomous responsibility to accept or decline applications for qualification.
• Even if a service provider met the assessment requirements, the supervisory body could still refuse qualification based on their assessment of the data center, enhancing oversight.
• Government Use of Qualified Trust Services:
• Government organizations in the Netherlands were required to use qualified trust services to ensure their identity and legitimacy.
• This requirement was seen as crucial for secure communication within NATO and to build trust.

Transition Away from Green Bar

• The transition away from the green bar indicator for trustworthiness in websites had posed some challenges.
• It was noted that the shift occurred around 2018 and continued.
• Discussions around new indicators were ongoing to maintain user confidence.

eIDAS Regulation Updates and Future Considerations

• The eIDAS regulation was undergoing updates, with a target effective date around 2024.
• Specific articles and requirements were still under negotiation.
• Discussions around uniformity, user-friendly indications, and potential changes in root stores were being considered.

Cooperation and Global Trust

• Cooperation between stakeholders, including browser vendors and certificate authorities, was seen as essential.
• Efforts were made to ensure that unilateral decisions did not jeopardize trust.
• Trust services and their regulation were expected to play a crucial role in the digital economy’s autonomy and sovereignty.

EU Participation in the CA/Browser Forum

• The possibility of the EU participating more formally in the CA/Browser Forum was discussed.
• Concerns about the requirement to sign an Intellectual Property Rights (IPR) agreement were raised.
• The need for further discussion and potential adjustments to participation requirements was acknowledged.

Future Trends

• Trust regulation was expected to become more prevalent in various sectors.
• The geopolitical situation and the emphasis on digital autonomy and sovereignty were influencing trust services.
• Trust services were being viewed from a perspective of autonomy and sovereignty

Browser Updates

Mozilla Root Program Update

Leader: Ben Wilson (Mozilla)

• Minutes:* Doug Beattie (Globalsign)
• Presentation link:* /uploads/2023-October-Mozilla-Browser-News.pdf

Discussion outside the presentation

There were no material discussion beyond what was presented.

Google Root Program Update

Leader: Chris Clements & Ryan Dickson (Google Chrome)

• Minutes:* Stephen Davidson (DigiCert)
• Presentation link:* /uploads/5-CABF-F2F-60-Chrome-Browser-Update.pdf

Discussion outside the presentation

1. Chrome Root Program Updates:

• Modern Infrastructures Survey Background and Motivation

  • Chrome believes that encryption makes the web more secure and protects users. In order for encryption to provide this security benefit, it must be consistently and reliably deployed.
  • Promoting modern infrastructures enhances that consistency and reliability – through simplicity and agility.

• when systems are simple they are easier to understand, use, and manage, leading to fewer errors and more consistent results.

• when systems are agile they can adapt to change and promote continuous improvement and reliability – while delivering their service.

  • Promoting Modern Infrastructures aligns with higher-level Chrome Root Program goals of promoting simplicity and agility.
  • Shared background on “Moving Forward, Together” initiative

• Long-term grouping of initiatives, first introduced at F2F 55.

• Non-normative, and therefore not policy.

• Shared publicly and in advance of any corresponding implementation timelines to identify existing and create new opportunities to help.

  • Described a tentative, phased approach for achieving the goals of “Moving Forward, Together.”

• Since MFT was first introduced, the Chrome team has had a lot of conversations about milestone sequencing, and coupled with the results from this most recent survey – heard and saw a desire for general sequencing.

• Naturally, by conveying an ordering or phasing, stakeholders can better prepare.

• The plan presented is tentative. The order may change as the Chrome team collects more data, studies community feedback, and as new threats emerge.

• If during exploration, it’s determined a goal cannot be achieved at the stated time without significant negative impact to the ecosystem, plans will be adjusted.

• Immediate focus is support for automation and term limit for roots included in the Chrome Root Store

• Both of these initiatives represent a commitment to simplicity and agility – and are fundamental for achieving many of the other goals described in MFT.

  • Chrome’s approach is influenced by data collected from a number of sources to include public tools like crt.sh and Censys, results from Chrome’s own experimentation, evaluating peer-reviewed research, and through using CA owner surveys. These tools help improve perspective and predict impact of areas of exploration.

• Survey, Findings, and Themes

  • Survey background:

• Goal: understand CA owner perspective related to impacts of “modern infrastructures” initiatives like term limit, reduced certificate lifetime, reduced domain validation reuse, etc.

• 100% of CA owners responded.

• 47% of CA owners provided comments to an open-ended question at the end of the survey.

• Chrome interpreted these results to indicate what was top of mind for most CA owners.

• 47% cited a negative impact or otherwise expressed concern associated with the proposed root term limit
• 26% expressed appreciation for the opportunity to offer feedback, and
• 22% asked for sufficient migration time before any future requirements should become effective.

• Chrome appreciates the candid responses provided by CA owners and will continue this approach in future surveys.

  • Survey results:

• Automation

• Chrome believes adoption of modern practices like automated certificate issuance and management help realize the full security value of TLS.

• Goals for and motivation related to automation were shared at F2F 59. If interested in learning more, refer back to that presentation.

• 76% of CA owners included in the Chrome Root Store stated support for automated solutions

• ~99.99 of the certificates issued in the Web PKI today are issued by these CA owners, estimated by combining survey responses and publicly available data.

• Noted that this data analysis was a point-in-time analysis, performed the week of September 21st.

• ~82 of the certificates issued by the Web PKI today are issued using some form of automation.

• This was extrapolated by considering CA owner survey responses against data from tools like crt.sh.

• The described data points, along with other feedback in response to the survey was interpreted by the Chrome team to indicate:

• broader support for automation by CA owners and corresponding service providers will continue to create better opportunities for website owners to improve the consistency and reliability of TLS implementations.
• support and innovation related to automation can help reduce the trade offs related to the time and effort required to adopt these practices.
• there are opportunities to improve the state of automation across the ecosystem to include increased availability of services, development of new features and product enhancements that will make adopting automation a better fit for certain types of subscribers, and opportunities to educate the user community on the opportunity automation presents.

• Chrome is planning a blog post about automation, to be published in the next week or so.

• Term Limits

• The Chrome Root Program feels a term limit for roots included in the Chrome Root Store will:

• Help promote and realize the gains of continuous improvement.
• Promote agility while discouraging potentially dangerous practices and eliminating single points of failure. It also allows adoption of new standards and security features not available when earlier roots were established.
• Reduce risk by re-establishing “known good” security baselines that may have been unknowingly lost over a period of time that is now sometimes up to 35 years. By reducing the period a root is relied upon, we reduce the maximum window of potential abuse.

• Refresher, MFT describes a proposal for a 7-year term limit. Survey questions were focused at understanding how that proposal impacts the ecosystem.
• Results:

• On average, CAs reported the “Active Signing Lifetime” which was described as “how long root CAs are used to sign new ICA certificates responsible for leaf certificate issuance - before transitioning to a new root?” – was about 15 years.
• Most respondents indicated “Active Signing Lifetime” was between 10 and 20 years.
• Though about 15% of CA owners aligned with the 7-year proposal, most do not.

• The most common theme shared by CA owners indicated that the proposed term limit would exacerbate the challenges of achieving root ubiquity – a critical user and device support story.
• Conclusions:

• Chrome identified concern, and some degree of risk communicated in response to the proposed 7 year term limit. Because of that feedback, Chrome will change its proposed approach. Specifics will be shared later in the presentation.
• A more agile approach is still preferred, and might be explored again in the future. It’s possible that over time, barriers to reduced functional life of roots will be removed – without additional active effort.
• Opportunities for innovation may also improve opportunities for agility.
• Chrome encourages CA owners to explore how they can adopt more frequent root rotation.

• Future Areas of Exploration

  • Described upcoming Chrome areas of exploration to include linting, phasing-out multi-purpose roots, and phasing out client authentication use cases.
  • Brief motivation for exploring these areas:

• Broader adoption of linting has the opportunity to reduce common mis-issuance events, resulting in fewer Web PKI incidents that typically do not materially affect the underlying security of TLS connections.

• Today, Chrome transitively trusts over 2,300 CA certificates

• About half of these CAs support use cases other than server Authentication - the only use case applicable for Chrome – and presumably other web-browser certificate consumers.

• Given that each CA trusted represents added attack surface, and given that the comingling of use cases minimally increases complexity, Chrome intends to phase out roots not dedicated to server authentication in the future.

• Chrome wants to understand the applicability of clientAuthentication use cases for web browsers and corresponding root store’s, like Chrome’s – whose use case for TLS is website authentication - not server-to-server or device authentication.

  • For these areas, CA owners can expect opportunities to share use cases and impact related to Chrome’s proposals. CA owner feedback is considered and valued.
  • If requirements are drafted, Chrome will do so in a way that attempts to minimize unintended impact and allows stakeholders time to prepare for and respond to changes.
  • Finally, these proposals will take time. As an example, Chrome began studying automation requirements almost a year ago, but the Chrome Root Program Policy does not yet have requirements related to automation.

• This point was again emphasized as it relates to leaf validity.

  • Described that exploring a reduction in maximum certificate validity is still and will remain a priority for the Chrome Root Program.

• Chrome is often motivated by thinking about the impact of “worst case” scenarios.

• For example, if we imagined an event like Heartbleed happening again…. are we adequately prepared to respond as an ecosystem? Are our collective users and customers in a position to respond quickly and completely to a vulnerability or incident that puts the foundation of web security at risk?

• As a community, and as leaders in this space, it is our combined responsibility to continue improving such that when we need to respond, we can – and without delay.

• Chrome believes the combination of automation and reduced certificate validity best positions us to manage risk and promote agility moving forward - and remains committed to exploring this further.

• Policy Updates

  • Chrome will be introducing a new “pre-flight” process, introduced at the last Face-to-Face, where CA owners can offer comments or request clarifications prior to a new policy version becoming final and effective.
  • Described the pre-flight process, and what CAs should expect related to timelines and next steps.
  • A summary of the updates included in the policy update were described. A point of emphasis was removing language from the Chrome Root Program policy and instead relying on reference to the CCADB policy, especially as it relates to incident reporting.
  • New subsections related to Root CA Key Material Freshness, Automation Support, and the Root CA Term-Limit

• Key Freshness: Updates are intended to be clarifying to more clearly describe expectations related to how CA owners can illustrate that pre-existing key freshness requirements are satisfied.
• Automation: New requirements such that applicants applying to the Chrome Root Program after January 15, 2024 must support some form of automation. ACME is preferred, however other solutions can also be acceptable. This outcome was influenced by CA owner feedback, as originally, Chrome intended to require use of ACME. There is no expectation or requirement that subscribers must use automation, just that CAs must make it an option for their use.
• Term-limit: New requirements that will limit a root’s inclusion in the Chrome Root Store to 15 years. This timeline was influenced by CA owner feedback provided during the recent CA owner survey. A specific phase-out plan is described in the policy update to reduce negative impact to the ecosystem as this change is implemented.

• Feature Launch Roadmap: The Chrome Certificate Verifier and Root Store have been deployed on all platforms, where possible. A FAQ link in the presentation materials describes more information about when specific platforms transitioned to the new Chrome tools.

2. Certificate Transparency Updates

• Chrome Security team members sent notice on 9/15 and 9/29 that several logs have been approved for inclusion in Chrome and are marked as Qualified.
• Chrome is always looking for new CAs to responsibly operate CT logs, and that these types of community contribution are evaluated when reviewing root store applications.
• Reach out to the Chrome team if interested in running a CT log.

3. General Browser News

• Beginning in Chrome 116, Chrome began offering support for Kyber.

  • This is not post quantum x.509 support, this is from the perspective of establishing symmetric secrets during the TLS handshake.

• Interested parties can learn more about this change in a blog post that’s linked from the slides.

Apple Root Program Update

Leader: Clint Wilson (Apple)

• Minutes:* Corey Bonnel (Digicert)
• Presentation link:* /uploads/6-2023-October-Apple.pdf

Discussion outside the presentation

Clint asked CT log operators to prepare sharded logs for 2026. Additionally, he would like to drive discussion on the state of CT log operators.

Clint provided a review of 2023:

Earlier this year, a new version of Apple root policy was published. The primary intention was to document previously undocumented requirements.

Additionally, a feedback cycle was introduced. This feedback cycle was very beneficial in terms of improving the root policy.

Several CAs opted to remove their S/MIME-issuing CAs from the Apple program instead of complying with the S/MIME Baseline Requirements, which came into effect on September 1st. Overall, the S/MIME BR implementation in preparation of the effective date was relatively smooth.

Clint provided a reminder of upcoming effective dates:

Apple will no longer accept multi-purpose root inclusion requests after April 15, 2024.

Apple will require CAs to support at least domain validation method for the issuance of serverauth TLS certificates that can be automated as of August 15, 2024.

Apple will require that S/MIME-issuing CAs provide a S/MIME BR audit report uploaded to CCADB by December 1st, 2024.

Clint reminded CAs that they need to share incident reports with Apple. If the report is available in Bugzilla, then a link to the incident is sufficient.

Clint said that several inclusion requests have been received where not all the requisite information has been provided. To move the request along, all required information must be provided.

Clint provided a preview of 2024 changes:

Addressing backlog items:

1. Website improvements to provide an archive of previous versions of the policy as well as a changelog

2. Clarify how updated versions of external documents that are referenced in the policy affect the policy

3. Improve language on key generation and protection requirements

4. High-level discussion on:

a. certificate validity periods and validation data re-use periods

b. use of subject DN attributes

c. requirements for the annual self-assessment

d. PQC: TLS certificates are not high priority, but other certificate use cases are

Clint would like input and suggestions for next steps, as it may be helpful to pilot initiatives in root policy before introduction of a requirement in the BRs. The IETF strongly recommends running code that implements a draft standard to ensure its feasibility. Clint also alluded to a hesitation by implementers to not implement something that is not yet required. It’s desired to understand the potential impact of a proposed requirement before it actually comes into effect and becomes a compliance issue.

Trev agreed that it is an involved process to add something to the BRs. She asked Clint if he’s implying that root policy is easier to implement as opposed to the BRs, as it is a compliance incident regardless of the source of the requirement.

Clint said that it’s not necessarily easier to modify root policy as opposed to the BRs, but rather that beneficial items have been originally introduced in root policies and later incorporated into the BRs. If there’s value in piloting a requirement before it becomes a compliance-impacting requirements, then the requirements better account for edge cases without CAs experiencing non-compliance incidents.

Jeremy asked if the scope of investigation on data re-use includes organization validation data, or is domain validation and mailbox validation reuse being considered. Clint clarified that the domain names expressed in the nameConstraints of technically constrained CA certificates was one facet. A wider view of all aspects of validation data re-use is being considered, but few concrete items yet.

Clint said that in Q1 or Q2 2024, a preview of an upcoming policy update in Q3 or Q4 next year will be circulated.

Microsoft Root Program Update

Leader: Hannah Sokol and Nitesh Bakliwal (Microsoft)

• Minutes:* Dean Coclin (Digicert)
• Presentation link:* /uploads/7-Microsoft_F2F60_Presentation.pdf

Discussion outside the presentation

• Question about the change in code signing certs accepting only RSA, what is the rationale for that?
• Answer: Not a change, that is what they currently support.

They looked at ECDSA but the ROI to implement that isn’t there at this time. Microsoft believes that exploring the approaches to support PQC as future, is better investment.

• Question: What’s the plan for MSFT to support PQC? Answer: Will be investing time to look at that now. It is the future approach and reason why we are not investing in ECDSA support exploration.
• Question: Which CT logs will be trusted. Answer: Not published yet.
• Question: Regarding upcoming SCT policy, is this a technical restriction or a root policy? Answer: Starting with a technical implementation but moving toward a root policy.
• Question: With audits, will you notify CAs if they have issues? With so many different root policies, we have to harmonize or else it’s not feasible. Answer: Yes, we intend to notify CAs. Also, Good point around harmonization, will likely piggyback on another root policies. However, all Mozilla, Apple, Google and Apple should meet and syncronize their CT policy.
• Comment: It would be preferable instead of having root policies, that these things go thru the CA/B Forum.
• Comment: Sometimes there are things that are out of scope of the forum.
• Comment: We should try to put as much in the forum as possible. CT is not part of BRs. Couldn’t that be part of the BRs? Would be good to discuss in forum.
• Comment: CT Log operators are an entity not envisioned in BRs and may not be CAs or Browsers. But you can make a conditional requirement, ( if you are a CA or brownser and operate a log then you must….).

CCADB Update

Leader: Ben Wilson (Mozilla, on behalf of the CCADB Steering Committee)

• Minutes:* Hannah Sokol (Microsoft)
• Presentation link:* /uploads/8-CAB-F2F-60-CCADB-Update.pdf

Discussion outside the presentation

Updates to the CCADB.org

August this past year, added policy on CCADB usage as well as tooling

Usage

– Ran into problem with license with Salesforce due to overuse. Had to add guidance around usage. < 5 log on per month (~ once per week)

– halved the use and we appreciate all the compliance around this

Tooling

– trouble maintaining the tools and se we moved to the GitHub. PEM Tool which is built into CCADB. Processes PEM file and processes CCADB with read only information (fixed bugs related to this parser)

– EV Readiness tool – paste in a PEM and run EV OID and the name of the server you are testing and test the cert against EV guidelines. URL will say what the testing does as well as a URL to the tool itself

Feature Updates: CA reports and Communications

Working on Audit Team Qualifications that is to come out this month

Click on “My CA” -> CA Reports

Report on all your certs and show your root / intermediate root ect. Helps with your audits and self-assessment

Generate this report, export to CSV, remove columns you dont need, and you then can use it for one of those two use cases

CA Communications

Shows all your comms that you have been partied to and things that have been sent out from your Root CA

Working on audit teams qualifications – upload button instead of referencing a URL. You would upload Auditing qualifications. This is for when something is separate (WebTrust) other roots stores are wanting it and so we added functionality to upload audit team qualifications

Under audit team there would be an upload button, what do you want to upload, upload file, and it will show the place where that is saved within CCADB

Is this for ETSI? This is mainly for WebTrust or any other auditor where auditing qualifications need to be used

Check box where we look at auditor team qualifications and if it satisfies the qualifications

What else is going on?

If you want to see request enhancements or bugs there is a link to the dashboard

We prioritize and triage the bugs

Can see the status and you are welcome to submit those as well

Add S/MIME fields to upload or populating data about SBRs

3.1 Announce incident reporting format

Taken current criteria and reorganized it into 7 different categories and will publish it at the end of the week. Ask that CAs start giving incident reports in this formal language and paste this into a Bug and it will break it into these categories

Put attached files in the appendix (ex. crt.sh hashes)

Don: When do you feel you will be ready for SMIME reports? To receive them?

Ben: We are ready now, it is just not stored in the CCADB. We will communicate among the root operators that here is the audit report. The person on call would review the SMIME audit reports along with other reports. It is not recorded in CCADB until we get this functionality. This should be delivered near the end of Q4

Don: Delayed parsing out Network Security report until you are ready to receive it in a separate template. We have the report and are drafting new reports to req the separation of Network Security. What is the timeline around that?

Ben: We have talked about this. Yes, it looks like we can do it at the same time as SMIME. There are time budgeting restrictions with our outsourced software dev. However, that was the planned approach to add the network security with (might be wrong, other members call me out)

Chris: Confirming that the desire is to align with those two new audit types. Work through CCADB steering committee requirements

Clint: More conversation around timing around separation of the root reports. That the criteria is separate. Will have emails back and forth to make sure

Q&A Root program discussions

Minutes: Arvid Vermote (GlobalSign)

Question: Are root programs open for CT harmonization?

Mozilla: Yes, as we drafted our policy we were under the assumption there would be consistency between root programs. Agreement it would be better to come to a common language.

Feedback: Suggestion to have the CT policy under CABF. Having multiple policies does not mean they are the same, the continue to require monitoring. Should have one document, one policy, one list of CT logs.

Apple: there are some outstanding quesitons: are the current policies causing conflicts / complexitieis or is it more a risk we see for the future? Other thought: if we shift it to CABF it would inherently end up being a different set of entities the policy applies to (right now, voluntary CA but might change if we move it to CABF)

Feedback: multiple examples were given about the potential complexitiies of the current “multiple policies” approach

Apple: open to consolidating but hoping everyone understands the implications

Microsoft is also open to jontly review and explore opportunity for consolidation and is already looking at Chrome and Apple policies as baseline

Chrome: CT policy is seperate from root program policy. There is an opportunity to align were the beliefs are common but there will always be independent root program requirements. Just because common requirements are aligned it does not mean the programs still might have seperate requirements.

Feedback: complying to all the different policies is diffirent, question to the root programs to make sure requirements are aigned. There is no reason why the root programs should come together, compare and make sure things aligned.

Aligned: alignment excercises are done during CT days.

Feedback: it makes sense for the browsers to have unique products, as long as the browsers continue to discuss stuff and work together to make sure a shared product does not break in a single browser because of their CT policy, that is what the CAs want to avoid

Question for Chrome: you said you wanted to phase out client auth. What would be the driver for that?

Chrome answer: we noticed that only 10% of certificates in scope within the Chrome root program contained client auth, not clear on the use case and no insights on what it would be. Awaiting feedback from further surveys what the consumer impact on removing client auth would be.

Feedback: the trust anchor for client auth is configured server side so having it chained to public trust anchors seems not needed, but maybe there are cases were there needs to be interoperability / consumers need multiple issuers for their client auth certificates.

Chrome: no intent to prohibit it from private PKI / other uses cases, only to remove it from TLS certificates

Audit Updates

ETSI Update

Leader: Nick Pope and Arno Fiedler (Chairs ETSI ESI)

• Minutes:* Clemens Wanko (TUV AUSTRIA)
• *Presentation link:**/uploads/10-ETSI-ESI-Activities-CABFORUM2023-10.pdf

ETSI summary of most important news (see slides for details)

Arno reported latest developments and updates from the ETSI/ESI normative developments. The overall map of available standards shows not only full coverage now but several updates supporting ongoing developments in all the different areas like:

• legal devs. at EU-level, like NIS2 and eIDAS2 as well as

• supporting CA/B Forum specifics, like S/MIME BR with the ETSI TS 119 411-6.

See slides for further details.

Discussion outside the presentation: No additional discussion.

ACAB’C Update

Leader: Clemens Wanko (TÜV AUSTRIA)

• Minutes:* Arno Fiedler (Vice Chair ETSI ESI)
• *Presentation link:**/uploads/11-20231003_CAB-Forum_60_ACABc_presentation_V1.4.pdf

ACAB’C summary of most important news (see slides for details)

Updates

• NIS2/Cybersecurity requirements for EU-based CA/TSP

• Clemens reminded CA/TSP based on EU grounds on upcoming caybersecurity requirements derived from th eEU directive on NIS2 (DIRECTIVE (EU) 2022/2555. Requrements following the directive will be defined, released by EU MS and adhered to by CA/TSP from 18th Oct. 2024 (Art. 41). Requirements for CA/TSP (mainly!) are addressed in updated ETSI EN 319 401. National MS specifics to be added to show full compliance.

• S/MIME BR audit integration

• ETSI TS 119 411-6 is interfacing between ETSI EN 319 411-1/2 requirements for CA/TSP issuing PTC

• and S/MIME BR. CA/TSP shall ensure that their CAB base audits on the …411-6 plus S/MIME BR and mention those in their reports including the AAL.

• Policy based AAL templates

• AAL concept change to improve CCADB AALV.

• New concept: a set of different attestations letters is required to form one complete audit attestation

• There is 1 standardletter template and 4 specific ones.

• Standard Audit Attestation Letter

• Lists all Roots and all corresponding SubCA (Intermediate & Issuing CA) that have been in the scope of the conformity assessment

• SMIME-BR Audit Attestation Letter

• List only the Roots and only the corresponding SubCA to the Roots (Intermediate & Issuing CA) that have been assessed against the SMIME BR (=> ETSI TS 119 411-6)

• TLS-BR Audit Attestation Letter

• List only the Roots and only the corresponding SubCA to the Roots (Intermediate & Issuing CA) that have been assessed against the TLS BR (ETSI policies DVCP, IVCP, OVCP, QNCP-w)

• TLS-EV Audit Attestation Letter

• List only the Roots and only the corresponding SubCA to the Roots (Intermediate & Issuing CA) that have been assessed against the TLS EV Guidelines (=> ETSI policies EVCP, QEVCP-w)

• Code Signing-BR Audit Attestation Letter

• List only the Roots and only the corresponding SubCA to the Roots (Intermediate & Issuing CA) that have been assessed against the Code Signing BR (=> ETSI policies NCP, NCP)

See slides for further details.

Discussion outside the presentation: No additional discussion.

WebTrust Update

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

• Minutes:* Bruce Morton (Entrust)
• Presentation link:* /uploads/12-Webtrust-CABF-update-Oct-2023-New-Format-v4.pdf

Some notes from the presentation

• WebTrust for S/MIME v1.0.1 has been issued.

• WebTrust for CA 2.2.2 in progress.

• Reporting templates being updated.

• Practioner guidance updated.

• Details controls reporting updated which is not a public report. The report is made up of 6 major sections.

• Impact of assessment of ISO 27099 on WebTrust. There were many changes. The rough draft showed too many issues. So now ISO 21188 is under review which will be updated and may contain items from ISO 27099. So WebTrust for CA should not be impacted until effort is done.

• WebTrust for Network Security report will be effective 1 April 2024.

• Still working on WebTrust for CA supporting X9 and IoT programs.

• Added two new members to the WebTrust task force.

• For a WebTrust audit a Signing Practioner is needed who must be WTCA licensed and PKI trained. Quality

• New seal pricing and bundles.

• Seal updates for RAs, S/MIME and Qualified Seal.

Discussion outside the presentation: none

Q&A Audits and Standards

Minutes: Kiran Tummala (Microsoft)

ADJURNED Forum Plenary Meeting for Day 1

CABF Face-to-Face Meeting 60: Day 2 October 4, 2023

CA/Browser Forum Meeting

Attendance

Aaron Gable – (Let’s Encrypt), Aaron Poulsen – (Amazon), Abhishek Bhat – (eMudhra), Adam Jones – (Microsoft), Adrian Mueller – (SwissSign), Adriano Santoni – (Actalis S.p.A.), Aleksandra Kurosz (Asseco Data Systems S.A.), Andrea Holland – (VikingCloud), Andreas Henschel (D-Trust), Aneta Wojtczak-Iwanicka – (Microsoft), Anna-Marie Christian (WebTrust / CPA Canada), Antti Backman – (Telia Company), Arno Fiedler – (ETSI), Arnold Essing (Telekom Security), Arvid Vermote – (GlobalSign), Ben Wilson – (Mozilla), Brianca Martin – (Amazon), Brittany Randall – (GoDaddy), Bruce Morton – (Entrust), Chris Clements – (Google), Christophe Bonjean – (GlobalSign), Clemens Wanko – (ACAB’c / TUV Austria), Clint Wilson – (Apple), Corey Bonnell – (DigiCert), Corey Bonnell (DigiCert), Corey Rasmussen – (OATI), Daryn Wright – (GoDaddy), Dave Chin – (CPA Canada/WebTrust), Dean Coclin (DigiCert), Dimitris Zacharopoulos – (HARICA), Don Sheehy (WebTrust), Doug Beattie – (GlobalSign), Ellie Lu – (TrustAsia Technologies Inc.), Enrico Entschew (D-Trust), Eva Vansteenberge – (GlobalSign), Hannah Sokol – (Microsoft), Hogeun Yoo – (NAVER Cloud), Ian McMillan – (Microsoft), Inaba Atsushi – (GlobalSign), Inigo Barreira – (Sectigo), Janet Hines – (VikingCloud), Jeremy Rowley – (DigiCert), Joanna Fox – (TrustCor Systems), Jochem van den Berge – (Logius PKIoverheid), John Mason (Microsoft), John Sarapata (Google Trust Services), Joseph Ramm – (OATI), Jozef Nigut – (Disig), Kateryna Aleksieieva – (Asseco Data Systems SA (Certum)), Keshava Nagaraju – (eMudhra), Kiran Tummala – (Microsoft), Leo Grove (SSL.com), Li-Chun Chen (ChungHwa Telecom), Lynn Jeun – (Visa), Mads Henriksveen – (Buypass AS), Marcelo Silva – (Visa), Marco Schambach – (IdenTrust), Martijn Katerbarg – (Sectigo), Michael Guenther – (SwissSign), Michael Slaughter – (Amazon), Michelle Coon – (OATI), Mohit Kumar (GlobalSign), Nargis Mannan – (VikingCloud), Nate Smith – (GoDaddy), Naveen Kumar – (eMudhra), Nicol So – (CommScope), Nikolaos Soumelidis (QMSCERT), Nitesh Bakliwal (Microsoft), Paul van Brouwershaven – (Entrust), Pedro Fuentes – (OISTE Foundation), Pekka Lahtiharju – (Telia Company), Raffaela Achermann – (SwissSign), Rebecca Kelley – (Apple), Rich Kapushinski – (CommScope), Rob Brand (Ministry of Economic Affairs and climate Policy (NL)), Rob Stradling – (Sectigo), Rollin Yu – (TrustAsia Technologies Inc.), Roman Fischer (SwissSign AG), Ryan Dickson – (Google), Scott Rea – (eMudhra), Sissel Hoel – (Buypass AS), Stephen Davidson – (DigiCert), Steven Deitte – (GoDaddy), Sven Rajala – (Keyfactor), Tadahiko Ito – (SECOM Trust Systems), Tim Callan (Sectigo), Tim Crawford – (CPA Canada/WebTrust), Tim Hollebeek (DigiCert), Tobias Josefowitz – (Opera Software AS), Tom Zermeno (SSL.com), Trevoli Ponds-White – (Amazon), Tsung-Min Kuo – (Chunghwa Telecom), Vijayakumar (Vijay) Manjunatha – (eMudhra), Wayne Thayer – (Fastly), Wen-Chun Yang (ChungHwa Telecom), Wendy Brown – (US Federal PKI Management Authority), Xiu Lei – (GDCA).

Definitions and Glossary WG

Leader: Tim Hollebeek (DigiCert)

• Minutes:* Stephen Davidson (DigiCert)
• Presentation link:* No presentation

Discussion outside the presentation

There was discussion to clarify the Charter language, including on end date currently included in the Charter, questioning if this creates unnecessary administration or accidental landmine to step on. Clint Wilson thought that end date would set impetus to deliver, and give the opportunity to revisit the charter after the initial deliverable. Dean Coclin questioned what happens if the WG initial task is not completed. Trevoli Ponds White supported the idea of setting milestones, but did not want to create Charter busy work. Scott Rea supported this. It was agreed to change the language to set a milestone rather than end the Charter. Paul van Brouwershaven suggested adding language for the WG to periodically reevaluate its goals.

There was discussion regarding changing name to Document Reform, with initial scope being definitions and glossary. Initial chair to get the group started is Tim Hollebeek, and vice is Brianca Martin from Amazon. Tim Callan also offering assistance.

There was discussion of the Charter language for goals and objectives. Stephen Davidson asked that procedures be clearly defined for interactions with other WG. Tim suggested that GitHub issues would be a good way to transparently track that work.

Tim described that the WG will not create normative requirements into definitions. It is only normative by its incorporation into other BR. This may include some restating of existing definitions.

Tim and Clint described how the consensus and ballot process matched the CABF bylaws.

Next steps are to get the charter letter finalized and out for vote. The goal would be start meetings in November. ??? commented that changes made by this WG can impact the requirements by other WG; this may require other WG to substantively update their own standards.

Proof-of-Concept for BR of BRs with requirements Matrix

Leader: Paul van Brouwershaven (Entrust)

• Minutes:* Tim Callan (Sectigo)
• Presentation link:* /uploads/15-20231004-Proof-of-concept-for-BR-of-BRs.pdfPaul van Brouwershaven (Entrust)

Discussion outside the presentation

Paul van Brouwershaven (Entrust): I have included links in the chat for this code if you want to see for yourself

Let’s look at how we manage documents, avoid duplication of content, and become more effective. This is my proposal and I wanted to demonstrate how it might work. This isn’t an attempt to get us to decide to do it this way. It is a demonstration.

Why I’m doing this. Objective is reducing duplication and enhancing clarity.

Benefits include, when we centralize baseline requirements into one document, it becomes much easier to manage and update. Think about org val information in code signing, S/MIME, and TLS. It’s mostly duplicated data.

This will promote consisstency. We don’t have to worry about inconconsistiences between documeemtns. Easier to adhere to because you only have to understand that section.

Efficiency.

Clarity.

This might require some challenges with IPR clearance. If we are separating or combining source documents, where do you review IPR. Definitions WG has a similar problem. Probably it means IPR clearance has to happen at a forum level rather than at a WG level. Perhaps everyone will be required to particiapate in that WG.

I’m sure we can deal with this, but we might need to rethink some things.

Layered approach. These things extend each other. DV is the minimum level. Then OV sits on that. And then EV on top of that. Certificate profile requirements are up at the top. You can simply exclude layers to drop to a lower authentication level.

Transforming the RFC 3647 formatted documents. Each chapter has a subdirectory. That means we have small documents, each containing a single section. The small documents are easier to manage.

With full BRs, migration takes a long time. Large docs are hard to navigate. Identifiying changes is difficult. It’s easy to mess up a large document. Merging layers of documents can be very difficult.

These layers are created based on the weight of what they are saying. There is an explanation of this in the slide deck, p. 10.

Right now we write paragraphs, which can require interpretation for what the distinct requirements are. In this format, the actual requirements are spelled out. We can filter documents based on target profiles. Allows control statements. Allows CAs to incorporate in a GRC system. Helps with self-assessments.

This is a lot like what they’re doing in ETSI.

Advanced instructions are a possibility. I built instructions for appendices to include only in the BRs and ignore everywhere else.

The generated BR doc is equal to the source doc.

Code signing and S/MIME include some TLS specific requirements. This is easily solved.

There is also an option to specify a level of assurance.

Let’s look at how this actually works. (Paul gives a demo of the data structure.)

Dimitris Zacharopoulos (HARICA):

I understand we should align the different sections of the different documents. It’s an easy concept but I imagine there is some work to get to this.

Paul:

The nice thing is we can migrate paragraph by paragraph over time.

Tim Hollebeek (DigiCert):

Agreed. The hard part is building it out and figuring out how things work and whatnot. Talking in abstract is easier then getting the details right. I’m keen to give this a run and see how it works. If we don’t run into too many problems, we can continue to maintain this and let it evolve as we move over.

Paul:

Right now we don’t use the same headers across documents. This would solve that.

[Paul demonstrates how to use an existing section from the BRs and extend with an additional text. Paul shows how to add an additional layer in the middle of a section.]

Trevoli Ponds-White (Amazon):

I love the idea of having a BR of BRs. I thought the intent was to capture requirements that are similar. I can see how this is an IPR challenge. It looks like the proposal is the group would maintain the section that goes in all the BRs. I would think it would be for the individual working groups to pull in the sections they want.

Paul:

If you look at what we’re doing, maybe 80% to 90% of content is the same. If we have a WG that works on the BRs, that would be baseline rquirements that everyone is based on. The WGs shouldn’t question them. Then these groups would add requirements specific to their certificate types.

Trev:

Your first statement was it’s 80% the same. There should be one requirement. I’m trying to connect the dots between the text is the same and so I made individual files to make them different.

Tim:

Paul, the sections you wrote about underscore CS, for example, would be the responsibility of the code signing working group.

Paul:

I’ve demonstrated that here in the code owners. EVGs is server cert WG. Code signing is code signing WG. Nobody else can change that. The different files help us to do this on a slow pace where we think it’s needed. If we stay within one document, this will be a multiyear project that may never finish.

Aaron Gable (LE):

I love this. I love the ability of individual CAs to automatically generate their CP/CPS.

Paul:

You could add your own files and instead of writing requirements, put control statements in those files. You could automatically generate a self-assessment. We could support that from the forum to help the members maintain it.

Aaron:

Minor concerns. One, it seems like what you’re talking about here is three separate initiatives. Changing the way the maintian these documents. Take advantage of that tooling to unify and harmonize these documents. Let’s make it possible to automatically extract reqiurements. I love all three of these, but it seems like we should focus on the restucturing and do it with no diff to the documents, knowing it is groundwork. Let’s discuss and decide on these as three separate things.

When a WG decides the text in the BRs isn’t sufficient for us and we need to modify it to change the verbiage, Git is bad at displaying small diffs in modified files. Eventually we may have to band aid the fact that Git is bad at that.

Paul:

I included a script that when we transform documents, it will compare each section to the BR and remove if it’s exactly the same. The next step is to identify documents that were the same for 90% or 99%. This is the low hanging fruit for modification.

Trev:

The infrastructure WG set up all these docs in GitHub. It feels to me like this just the structure of what was set up. I figure most people don’t care. I don’t know if we need to BRs group to even care how these documents are created.

Aaron:

In my opinion, step one is tighten up the scripts so the output is virtually identical to the existing documents. And then let’s just start working. That first step doesn’t need a working group.

Trev:

It has a working group.

Paul:

If we want to, this can be done by infrastructure WG.

Clemens Wanko (ACAB’c):

Do I understand the idea is to support the WGs but not to use that as a final version to use? Remember, we need a stable version to work on.

Paul:

All these documents will be merged into the same documents we have today. The BR of BRs is exactly the same except space and no stipulation. Code signing is almost the same except renaming files. Similar for S/MIME.

Dimitris:

I think the bylines and WGs already cover this. Are there any objections to proceeding? This is just a transformation of GitHub that will product the exact same documents. We will need some poeple to support Paul in this.

Clint Wilson (Apple):

I like the way this is shaping up. Careful how we move forward. There are a lot of people where this is foreign space for them. Anything we can do to help anybody’s ability to engage with the BRs might make it easier. They only have to do one tiny document. Keeping the changes we initially make as additive, so there’s familiarity while we transition.

I’d love to have conversation about how you work with this written up, so folks can reference it as they start working with this.

Dimitris:

To propose changes, you don’t need to use GitHub if you’re not fluid in it. Use Word with track changes and work with someone who knows the GitHub process.

Paul:

I think this will make contributions easier because the files are smaller and the risk is lower. I hope this encourages more collaboration.

Clint:

If we have a list of ballot shepherds, that will help.

Paul:

We need to take this on in the infrastructure WG and take this to the next step.

ADJURNED Forum Plenary Meeting for Day 2

— END FINAL F2F #60 CA/B Forum Plenary Meeting minutes —