Day 1 February 26, 2024

CA/Browser Forum level Meeting

Attendance

Aaron Poulsen (Amazon), Aashish Banati (Office of CCA, MEITY, Govt of India), Abhishek Bhat (eMudhra), Adam Jones (Microsoft), Adrian Mueller (SwissSign), Adriano Santoni (Actalis S.p.A.), Andrea Holland (VikingCloud), Andreas Henschel (D-Trust), Antti Backman (Telia Company), Arno Fiedler (ETSI), Arnold Essing (Telekom Security), Arvid Vermote (GlobalSign), Arvind Kumar (CCA, MEITY, Govt of India), Ashish Dhiman (GlobalSign), Balaji Rajendran (CDAC India), Ben Wilson (Mozilla), Bilal Ashraf (SSL.com), Brittany Randall (GoDaddy), Bruce Morton (Entrust), Christophe Bonjean (GlobalSign), Clint Wilson (Apple), Corey Bonnell (DigiCert), Dave Chin (CPA Canada/WebTrust), Dean Coclin (DigiCert), Dilip Barman (Office of CCA, MEITY, Govt of India), Dimitris Zacharopoulos (HARICA), Dustin Hollenback (Microsoft), Enrico Entschew (D-TRUST), Eva Vansteenberge (GlobalSign), Fumi Yoneda (Japan Registry Services), Hogeun Yoo (NAVER Cloud Trust Services), Inaba Atsushi (GlobalSign), Iñigo Barreira (Sectigo), Jeremy Rowley (DigiCert), Jos Purvis (Fastly), Jozef Nigut (Disig), Kateryna Aleksieieva (Asseco Data Systems SA (Certum)), Kaushik Srinivasan (eMudhra), Keshava Nagaraju (eMudhra), Kiran AM (eMudhra), Leo Grove (SSL.com), Li-Chun Chen (Chunghwa Telecom), Mads Henriksveen (Buypass AS), Marco Schambach (IdenTrust), Martijn Katerbarg (Sectigo), Matthias Wiedenhorst (ACAB Council), Miguel Sanchez (Google), Mike Kushner (Keyfactor), Mrugesh Chandarana (IdenTrust), Nargis Mannan (VikingCloud), Nate Smith (GoDaddy), Naveen Kumar (eMudhra), Nicol So (CommScope), Nitesh Bakliwal (Microsoft), Nome Huang (TrustAsia), Paul van Brouwershaven (Entrust), Pawas Chandra (Jio Platforms Limited), Peter Miskovic (Disig), Rich Smith (DigiCert), Raffaela Achermann (SwissSign), Ramachandran P (Office of CCA, MEITY, Govt of India), Rollin Yu (TrustAsia), Roman Fischer (SwissSign), Sandy Balzer (SwissSign), Scott Rea (eMudhra), Sissel Hoel (Buypass AS), Sooyoung Eo (NAVER Cloud Trust Services), Star Simmons (GoDaddy), Stephen Davidson (DigiCert), Sven Rajala (Keyfactor), Tadahiko Ito (SECOM Trust Systems), Thomas Zermeno (SSL.com), Tim Callan (Sectigo), Tim Hollebeek (DigiCert), Trevoli Ponds-White (Amazon), Tsung-Min Kuo (Chunghwa Telecom), V. Srinivasan (eMudhra), Vijayakumar (Vijay) Manjunatha (eMudhra), Yashwanth (eMudhra).

Approval of CABF Minutes from last teleconference

• Leader: Dimitris Zacharopoulos (HARICA)

The draft minutes have not been distributed yet.

Future face to face meeting schedule

• Leader: Dimitris Zacharopoulos (HARICA)

  • Summer 2024 meeting will be hosted by Actalis in Bergamo, Italy
  • Fall 2024 meeting will be hosted by Amazon in Seattle, WA, USA
  • Spring 2025 meeting will be hosted by SECOM in Tokyo, Japan
  • Summer 2025 meeting will be hosted by CPA Canada in Toronto, Canada

Discussion outside the presentation: No further discussion.

Guest Speaker

• Presenter: Balaji Rajendran - Associate Director at CDAC (Centre for Development of Advanced Computing) India
• Title: Strengthening the Ecosystem of Digital Trust
• Presentation link: Strengthening the Ecosystem of Digital Trust
• Presentation Notes:

Digital Trust requires assurance of all entities and corresponding informational flows within an ecosystem. Users navigate the Internet primarily through the domain names that they could put it on the address bar of the browsers, which could be from their memory or from other applications. In this talk, we look at ways that could help the users with a reputation of the domain names that they are accessing, and in a way protecting them from malicious domains and websites. We specifically look at DANE, and AI enabled techniques that could help in creating an environment of trust for the users. In the end, we also discuss about India’s effort for developing a Web Browser catering to indigenous requirements

Forum Infrastructure Subcommittee

• Leader: Jos Purvis (Fastly), Ben Wilson (Mozilla)
• Minutes:
• Presentation link:
• Discussion minutes:

Open Mic

• Discussion leader: Dimitris Zacharopoulos (HARICA)
• Minutes: Tim Callan (Sectigo)

Sven Rajala (KeyFactor): Can recurring guests like me get read-only access to the wiki?

Dimitris (CABF Chair, HARICA): Yes, this is a burden for us also. Let’s look at changes to the by-laws.

Dimitris: There are several regular guests who don’t have access to the wiki. I have to communicate when we change the agenda,

Paul van Brouwershaven (Entrust): Inigo has talked about distribution of work. Some of the work currently has to be done in membership tools, Google sheets, etc. We are doing some things in multiple places and perhaps making unnecessary work.

Dimitris: There are Interested Parties that attend regularly which means they have permission to attend all Teleconferences. We haven’t given access to the Wiki because attendance to the meetings is by invitation only. I believe if the chair of the forum or working group has extended such an open invite, we should be able to give access to the members website. Are there any objections for that?

Dustin Hollenback (Microsoft): Would that be read only access or read/write?

Dimitris: I believe everyone has read/write.

Paul: What would the objective of just giving read only access? Observers might want to do things to help and move forward.

Dimitris: Interested parties have signed the IPR and have every right to contribute. They can register themselves to F2F meetings, contribute to minutes, etc.

Clint Wilson (Apple): I don’t have a conceptual objection to this but I’d like to understand more clearly what comes with that. I want to make sure we look at that pretty closely and are aware of what they are able to do.

Tim Hollebeek (DigiCert): If the problem we’re trying to solve is just around meeting logistics, etc. we should think about moving that to a more accessible spot. Our interested parties so far have been well behaved, but the bar for joining is low, so I think we might be smart to find a conservative solution.

Trevoli Ponds-White (Amazon): What are we after? What is the danger?

Dimitris: I am referring to interested parties that have received an invitation, especially those that have open invitations.

Trev: Is there a list of which interested parties are allowed to attend everything and which are not?

Dimitris: We could have a more formalized way if that would be an improvement.

Trev: There should be a process of reviewing their access. With the companies, we know when someone left the company and removed. But that may not be true with interested parties. Maybe once a year we review them.

Dimitris: As Tim said, interested parties so far have behaved well. If that changes, we can remove the invitation.

Paul: Remember, we have a code of conduct. If needs be, we can change it.

Inigo Barreira (Sectigo): I have concerns with this. For example, I have recently added some interested parties. In the forum by-laws it says, a chair can invite someone, but the server cert working group rules are silent on this matter. Since both calls use the same slot and phone number, it’s unclear if this is allowed. Since the guests don’t have wiki access, we will need to send them the WebEx info. It’s not just allowing them to attend, it’s also the logistics of it.

Dimitris: Where chartered WGs are silent, we take guidance from the Bylaws. Interested parties are not automatically invited to teleconferences. They are only allowed to post to the public list. Attending teleconferences is an additional step that requires approval of the chair. Inigo is right that we have a shared session. Technically, if we invite an interested party, both chairs would have to approve. Such disagreement hasn’t come up, so I’d rather not make it more complicated than it needs to be.

Scott Rea (eMudhra): So do we want to create levels of interested parties. On the membership side we have full members and associate members and there is a difference on what they can do.

Martijn Katerbarg (Sectigo): We already have a member category called associate members. Isn’t this exactly what this is for? Should an interested party that has a standing invitation become an associate member?

Dimitris: We have to look at the definition of associate member. We just added a probational member. I’d rather not change the categories to accommodate an administrative issue. I don’t want to add a lot of administrative overhead.

Martijn: Looking at the definition in the Bylaws, that appears to be exactly what it’s for.

Dimitris: Let’s explore that.

Ben Wilson (Mozilla): I support the position about not revising Bylaws.

Tim: Strong support for not adding categories, or changing Bylaws.

Paul: The associate member idea seems to be appropriate. Would KeyFactor be an appropriate associate member? If it’s a one-time invitation, then it’s fine. But if they’re doing this for many years, let’s talk about an associate member with more formal access and privileges. I would distinguish between a one-time guest and a member that has been doing this for a long time.

Dimitris: Historically associate members have been regulatory bodies, auditing bodies, supervisory bodies, and things like that.

Tim: I don’t believe that’s correct. It’s been used for CAs that are not trusted yet. That’s been prominent for a long time. KeyFactor is not far away from that. I think that’s are reasonable solution.

Trev: Are we just trying to give KeyFactor access to the wiki or auditors also? We should give everyone the same access and not based on vibes. That will be easiest to manage.

Dimitris: If there are no objections, let’s think about extending KeyFactor an invitation as an associate member.

Dimitris: We have duplication of attendance between the meetings.

Inigo: We recently had some ballots so we have to create the ballot column in the Google list and also in the member tool. The member tool tells us who voted but won’t crate a quorum. We are duplicating work. Same when adding new members, interested parties. etc., we have to do it in several places. I have to do stuff twice and would rather have it in one place.

Paul: We discussed moving certain management functions to the management tools, which are managed by infrastructure working tools, specifically Martijn. With the new site we automatically link to the working tools for some things. Hopefully we can extend that to the entire membership list. This is to reduce the work burden on chairs. I agree it’s duplication but we can’t just tell Martijn to do that because he has another job too. I think it’s good to talk about how to manage it. It would be good to have more participation in the infrastructure working group. Or could we get agreement to fund certain things.

Dimitris: Support for Martijn would be great. This is a voluntary group, but we do have to set aside to make this work. The forum is the members. Not only ideas but also practical work. The membership tool has solved a lot of problems, but we still have a long list of things. The more we put in to infrastructure subcommittee, the better results we will get. With regard to voting in particular, the transparency the spreadsheet provides, is important. If it moves to the membership tools, we still need a presentation that has a similar effect.

Paul: Membership tools can make that easier. The information in the membership tool can be exposed back to the website in a Git repository where there is a record of what is done to that. Ballot information can be automatically exported to the website. We may not know PHP ourselves, but we all represent organizations that have resources. The individuals who are supporting CABF do not need to be the same as those that are working on standards.

Dustin: Is there a list of the tasks that need help. If I had that, I and probably others can go ask.

Paul: We generally are doing a lot on GitHub. I’m not sure if there is an actual list, but maybe that’s a good question for the infrastructure working group.

Ben: This is a call to action for the broader membership, not a mandate on the Infrastructure Subcommittee.

Martijn: The tooling does do that, but we need to confirm it is working. If you don’t know how to program but would like to help, I could use help with documentation because that’s lacking. Please reach out to me.

Corey: Can we take these tasks and put them on the appropriate repositories in GitHub? That way people can look and see if there’s anything then can do.

Dimitris: Let’s try to organize the backlog and create a list of tools we are using to share with the larger forum.

Trev: The task in GitHub should contain the tool so that it’s easier. We don’t need a separate list of tools if they are in the associated tasks.

Paul: The list of tools helps identify if your organization has certain resources. The wiki also needs some help on organizing, eliminating duplication, etc.

Corey: With the exception of the wiki, we have GitHub repos for everything.

Paul: Do we see any other areas where the forum could improve structural organization and tools?

Dimitris: Let’s try to have this conversation with Jos present. Let’s move on to Nitesh’s topic.

Nitesh: eIDAS is going for a vote later this week. What is our thinking about how CABF can play a role in influencing these standards?

Dimitris: Each forum member represents its own opinion. There is no one unified opinion. The best approach is to have extended participation in ETSI. Right now the ETSI standards are well aligned to CABF BRs and EVGs. There are additional ETSI policies that don’t need to align with CABF. There has been a lot of work collaborating to keep these bodies aligned.

Nitesh: Do we feel there is a delta between the BRs and the eIDAS standard.

Arno Fiedler (Nimbus): I don’t see a delta, but we should look at the final version of eIDAS 2. I expect a vote this week but it may be postponed. The browsers are active ETSI members, so we try to keep this delta as small as possible.

Paul: The Dutch ministry has indicated it would be willing to engage more closely with CABF. We have heard similar interest from India. What is our interest in engaging with governments?

Clemens Wanko (ACAB’c): The auditors don’t expect big changes based on eIDAS 2. eIDAS 2 will reference an “implementing act,” which is where it will specify how these are to be implemented. About how to interface with authorities, there is an association of supervisory bodies in Europe. How can CABF join these platforms to provide information to the European ecosystem.

Tim: We have a chartered scope of activities. Getting the CABF involved in politics and lobbying is a bad idea. We could have a formal liaison relationship between the group. Having government representatives on CABF committees, we would have to be careful how we set that up. I think it’s best that CABF stay true to our purpose and not expand into other areas and Europe specific forums. It’s difficult to come to a consensus of what CABF thinks as a body. I have a hard time seeing how this would work.

Trev: In addition to what Tim said, I doubt a lot of our companies’ lawyers would let us.

Dimitris: I think Paul’s position is different than that. It has to do with the idea that supervising authorities and auditors may have concerns. We already have extended an invitation to regulatory and supervising bodies. We would keep it to technical matters, not political. Clemens, with eIDAS 2, you won’t just be auditing CAs, you might even audit Browsers.

Clemens: Yes, and we have other standards integrating in. We are synchronizing that also.

Scott: I agree with Tim. We need to stick to the scope of what we were organized for. But there is a real challenge in the world of trust services that there is not a lot of broad experience. A lot of that experience sits in this room and on this call. So if there was a way to facilitate a dialog, maybe a voluntary liaison with these organizations, if there was a place organizations could go to directly connect with the members, that’s what these organizations are looking for.

Browser Updates

Mozilla Root Program Update

• Leader: Ben Wilson (Mozilla)
• Minutes: Arvid Vermote (GlobalSign)
• Presentation link: Mozilla Browser Update

Discussion outside the presentation:

Root CA Lifecycles - Ben is working on a CCADB design document to create Root Program and CA task lists for retiring roots, which would be based on a report of key generation dates. From the reports we could use the CCADB for calendaring/alerting sufficiently in advance about the need to remove or distrust a root (e.g. heads-up alerts by year 13 and highlight for year 14). For this to work, we will have to ensure that CA operators have populated the Key Generation Date field in the CCADB.

S/MIME Compliance, Incidents and Audits - We are still going through a transition phase in which CA operators have discovered that they did not foresee the complications they would face in creating BR-compliant issuance systems. However, going forward we will be scrutinizing these incident reports more closely. We have received a few audits for compliance with the S/MIME Baseline Requirements.

Submission of Compliance Self-Assessments - CAs should be updating the CCADB with links to their most recent Compliance Self Assessment. The most recent version of the Compliance Self Assessment is at https://www.ccadb.org/cas/self-assessment.

A summary of bugzilla incidents was provided

Ben highlighted the different root causes identified based on recent mis-issuance incidents:

• Not designing systems and operations to meet requirements
• Human error
• Misplaced reliance on API’s, Enterprise RAs, DTPs, IDPs …
• Inadequate Quality Assurance / regressions when updating systems
• Pre-linting failed to stop issuance
• Testing in a production environment

Period-of-time key lifecycle management reports - GitHub Issue #275 Improve discussion in MRSP of how CA operators can prove cradle-to-grave CA key protection by complying with expectations and requirements for period-of-time audit reporting (just for CA key protection, but does not involve issuance activity). This might include an effort to address “parked” CA keys.

Policy on incident reports consistent with CCADB Policy - GitHub Issues #270 and #271 These issues are relatively minor. The MRSP will be revised either by using nearly identical language from the CCADB Policy or by pointing to the CCADB Policy. See https://www.ccadb.org/cas/incident-report.

After almost 16 years working on Mozilla’s Root Store Program and 8 years working on the CCADB, Kathleen Wilson is retiring as of February 29, 2024. We are greatly indebted and extremely thankful to Kathleen for the work she has done.

A question was asked what the vision is on cradle to the grave, Ben explained that a key generation report and period-over-time report as soon as possible is critical when it comes to the trustworthiness of a CA (key pair). As for the “grave” part of a root, continuous audits are required until the CA expires or is destroyed.

Another question was asked related to Mozilla’s root store independence from the operating system. Ben commented there is no plans to change the current modus operandi.

There was a question on CA inclusion request timelines and transparency thereof, Bugzilla queries can be created for that, when it comes to how quickly Mozilla can respond to initial requests requires some additional digging. The processing time also depends on the classification / priority of the request per https://wiki.mozilla.org/CA/Prioritization

Apple Root Program Update

• Leader: Clint Wilson (Apple)
• Minutes: Corey Bonnel (Digicert)
• Presentation link: Apple Update

Discussion outside the presentation:

Two policy updates in 2024.

one minor update with formatting and structure. Available in draft 1-3 months, publication in 4-7 months.

A major update that introduces changes to the policy itself. Some potential changes include VMC policy and changes regarding cross-certification.

Trev: I think there’s been good work to improve instructions for incident reporting. However, something that is missing is developing a culture of creating incident reports. Internally at Amazon, we review historical reports to identify how to improve reporting. It would be helpful if Root Programs highlight exceptionally good reports or elements of others that can be improved.

Clint: I agree. However, it is a challenge to do in a public context. We do discuss how to improve reporting with CAs privately.

Trev: It should be a partnership. One option is to privately contact CAs with identified reports to see if they’d like to have their report raised publicly.

Clint: Agreed.

Enrico: How do we provide feedback on policy? Can we raise questions on CCADB?

Clint: We privately discuss with CAs right now and have no plans to change that. In addition, we have surveys to communicate changes.

Brittany: You mentioned that there’s a April 2024 deadline for new multi-purpose roots. Is that the cut-off date where multi-purpose roots will no longer be accepted?

Clint: Yes.

Brittany: What do you mean by multi-purpose root?

Clint: Section 2.1.3 of the root program policy should provide the details.

Tadahiko: For clientAuth EKU roots, can we include other EKUs?

Clint: It would depend on which EKUs are considered to fall within the clientAuth category.

Tadahiko: You have a category for clientAuth, which might be confused with EKU.

Clint: We can consider modifying the language to make this more clear

Microsoft Root Program Update

• Leader: Nitesh Bakliwal (Microsoft)
• Minutes: Dustin Hollenback (Microsoft)
• Presentation link: Microsoft Update

Discussion outside the presentation:

CCADB Update

• Leader: Nitesh Bakliwal (Microsoft) and Ben Wilson (Mozilla)
• Minutes: Tim Callan (Sectigo)
• Presentation link: CCADB Update

Discussion outside the presentation:

Nitesh: ccadb.org updates Transitioning away from the Mozilla organization to the Linux foundation.

CCADB policy updated 10-23 Clarifying language. CA owners must disclose authorititive English language version of policy docs Added audit team qualifications

Self-assessment updated 1-24 Instructions for cover sheet Mozilla, chrome self assessments

Added by-laws Replaced previous document

Updated usage terms Have removed references to Mozilla

System feature updates Audit team qualifications Goal is to simplify and consolidate

NetSet and S/MIME audits Added to CCADB cases

AllCertificateRecordsCSV Formatv2 Added to CCADB May deprecate v1 in the future

Case status updates Will communicate case status updates by email notification

Coming soon CCADB update dashboard CCADB prioritization process

Trevoli Ponds-White (Amazon): It’s weird that a database tool has a policy rather than instructions for use. Unless there is a reason for it to have a policy, it should have instructions that tell you how to meet browser requirements.

Ben Wilson (Mozilla): Whether or not we call it a policy, that’s just one aspect of CCADB. There is also distribution of information that is not in the database. Like the email list, repositories for information. We are a collection of root store programs with our own impressions of how this should work.

Trev: Maybe there could be a common guide for incident reports and Mozilla’s policy could require that you follow the guide.

Clemens Wanko (ACAB’c): Do you foresee an auditors’ view into CCADB to view their customers for digestion problems with report upload, etc. That would be really helpful for us. As a reminder, we would like to change the reporting to an electronically readable format like XML. That could help making things digestible.

Ben: There are resources considerations for both these items. For the auditors view there will also be licensing and interface matters we need to figure out. We would need to track which auditor is associated with which CA.

Clint Wilson (DigiCert): For the auditor view, we haven’t identified exactly what auditors need access to. CAs can test audit reports today and there are specific instructions. We have heard auditors are using this. It’s a massive effort to add auditor view and there will have to be a very concrete need before it will be prioritized.

Clemens: CAs could self-declare who their auditors are. There is a formal process behind the audit submission. It’s a bit late to be able to test the report once the submission process occurs. This results in wasted effort.

Ben: We could think out loud about our options. CA can provide you with SHA hashes when you’re preparing an audit letter. Maybe there is a way to not use CCADB but to build another tool that plugs into ALV processing to give you the results. With ETSI audits, now that we’ve gone to separate audit attestation letters fro the certificate types, it’s not what the CA is issuing but what it’s capable of issuing. If the root is trusted for TLS, it will expect that audit even if the root is called Code Signing CA or S/MIME CA. We need to communicate that to our European CAs and their auditors.

Clemens: We will talk to the CAs.

Mrugesh Chandarana (IdenTrust): Is the effort to limit the Salesforce logins still in force.

Ben: Yes, our licensing with Salesforce has a certain expected volume. We don’t want to have to upgrade the expense based on number of logins.

Aaron Poulsen (ATS): Is there an expected cut-over date for switching to the Linux foundation?

Ben: May 4

Q&A Root program discussions

Minutes: Mrugesh Chndarana - IdenTrust

Dimitris: I understood the message from Trev that some policies are migrated from certain root programs and migrated to CCADB policy. Trying to understand whether the name policy is a problem?

Trev: It makes sense to have instructions and policy like this is how you update your case or incident.

Dimitris: For example, At the policy level, it says you need to report to CCADB in 7 days if you update your CP CPS.

Ben: If all the root program agrees to something then it goes to CCADB policy.

Paul: CCADB as an org is still in its early days and may be shifting certain policies into CCADB policies. This is one policy that is easier for CAs to comply with. We need to give more time to Root programs to harmonize and come up with a concrete CCADB policy.

Trev: For incident report. if you haven’t properly reported an incident you may need to open another incident for that. If you pull out instructions from the policy and explaination for the fields then it would make it easier to understand the policy vs. instructions.

Scott: It seems like we got some SRPs in the policy which probably don’t belong there.

Nitesh: CCADB team can look into that and try to figure out how we can change that going forward.

Dimitris: Auditor to have access to API for ALV.

Ben: I’m not promising anything.

Dimitris: It provides a tool for auditors to test a lot of things.

Ben: CCADB actually tests that and not all are done through ALVs. ALV sends notifications.

Dimitirs: Auditor needs to have access to full ALVs and it may require full access to CCADB. It’s been in the backlog for some time.

Ben: There is a workaround for CAs to work with an auditor to test it and then submit it. They have to coordinate with the auditor to test ALV.

Martin: Question for Microsoft Root program: It looks like the update was already released by Microsoft 5 days ago which talks about removing EV code signing OIDs. They don’t list the SMIME OIDs either.

Nitesh: It’s news to me and will follow up with the team and provide better details.Audit Updates

ETSI Update

• Leader: Arno Fiedler (Vice Chair ETSI ESI)
• Minutes: Clemens Wanko (TUV AUSTRIA)
• Presentation link: ETSI Update

ETSI summary of most important news (see slides for details): Arno explains recent updates in ETSI standards

• TR 119 411-5 Co-existence Browser Root store and EU Trust List (QWAC). Discussions continue on 2 certificate approach.
• TS 119 411-6 alignment with CA/Browser forum S/MIME certificates. Published.
• TS 119 461 Update including: (Qualified) Electronic Attestation of Attribute. Identity assurance level ‘high’. Support identity proofing for EUDI Wallet.
• EN 319 401 draft incorporating NIS2: is under national EN approval.
• Revised TS 119 615: Procedures for using and interpreting European Union Member States national trusted lists. Published. Further updates planned to take into account: Third Country AdES Trusted List e. g- Ukraine

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: ACAB’c Update

ACAB’C summary of most important news (see slides for details): Clemens Wanko and Matthias Wiedenhorst report on the on the very pleasing growth in ACABc membership and the update on Audit Attestation Letters, now with a PKI usage specific amendment. Apart from this, the CA/TSP located on the grounds of the European Union were reminded to have an eye on upcoming Cybersecurity/NIS2 requirements becoming applicable in October 2024. Compliance to these requirements must be included in their audit reports. Clemens strongly suggests that CA/TSP consult their auditors and their responsible SB on that in order to ensure appropriate reporting in timely manner.

Discussion outside the presentation:

Paul: Is there a idea on how CA/TSP treated regarding NIS2/Cybersecurity providing their services in/for Europe but residing outside of the European Union? Clemens:
Question can not answered right away. Clemens will take that into the meeting with the European supervisory bodies (FESA/ECATS) in April for further discussion and will report any news at the upcoming Bergamo, 62nd CA/B Forum meeting.

WebTrust Update

• Leader: Dave Chin, (CPA Canada)
• Minutes: Arvid Vermote (GlobalSign)
• Presentation link: Webtrust Update

Discussion outside the presentation:

New update to the practitioner guide will be published within a month.

There is new updates to all different WebTrust’s coming out within March.

Separate WebTrust for Network Security, so also updates to references in the other WebTrust

Reporting Templates have been updates as well, including paragraphs to acknowledge service providers

Separate seal for network security as well

WebTrust task force is working on other projects such as X9, IOT certification ….

Considerations on how to audit / establish controls for the use of third parties

New practitioner portal went live February 2024

In a second phase of the Website revamp the practitioner & certificate authority location visualization

A meeting with ACAB’c happened again in Berlin December 2023

EY practitioner will be listed by legal entities instead of only EY US

Q&A Audits and Standards

• Minutes: Brittany Randall (GoDaddy)

ADJURNED Forum Plenary Meeting for Day 1

Day 2 February 27, 2024

CA/Browser Forum Meeting

Attendance

Aaron Poulsen (Amazon), Aashish Banati (Office of CCA, MEITY, Govt of India), Abhishek Bhat (eMudhra), Adam Jones (Microsoft), Adrian Mueller (SwissSign), Adriano Santoni (Actalis S.p.A.), Andrea Holland (VikingCloud), Andreas Henschel (D-Trust), Antti Backman (Telia Company), Arno Fiedler (ETSI), Arnold Essing (Telekom Security), Arvid Vermote (GlobalSign), Arvind Kumar (CCA, MEITY, Govt of India), Ashish Dhiman (GlobalSign), Balaji Rajendran (CDAC India), Ben Wilson (Mozilla), Bilal Ashraf (SSL.com), Brittany Randall (GoDaddy), Bruce Morton (Entrust), Christophe Bonjean (GlobalSign), Clint Wilson (Apple), Corey Bonnell (DigiCert), Dave Chin (CPA Canada/WebTrust), Dean Coclin (DigiCert), Dilip Barman (Office of CCA, MEITY, Govt of India), Dimitris Zacharopoulos (HARICA), Dustin Hollenback (Microsoft), Enrico Entschew (D-TRUST), Eva Vansteenberge (GlobalSign), Fumi Yoneda (Japan Registry Services), Hogeun Yoo (NAVER Cloud Trust Services), Inaba Atsushi (GlobalSign), Iñigo Barreira (Sectigo), Jeremy Rowley (DigiCert), Jos Purvis (Fastly), Jozef Nigut (Disig), Kateryna Aleksieieva (Asseco Data Systems SA (Certum)), Kaushik Srinivasan (eMudhra), Keshava Nagaraju (eMudhra), Kiran AM (eMudhra), Leo Grove (SSL.com), Li-Chun Chen (Chunghwa Telecom), Mads Henriksveen (Buypass AS), Marco Schambach (IdenTrust), Martijn Katerbarg (Sectigo), Matthias Wiedenhorst (ACAB Council), Miguel Sanchez (Google), Mike Kushner (Keyfactor), Mrugesh Chandarana (IdenTrust), Nargis Mannan (VikingCloud), Nate Smith (GoDaddy), Naveen Kumar (eMudhra), Nicol So (CommScope), Nitesh Bakliwal (Microsoft), Nome Huang (TrustAsia), Paul van Brouwershaven (Entrust), Pawas Chandra (Jio Platforms Limited), Peter Miskovic (Disig), Rich Smith (DigiCert), Raffaela Achermann (SwissSign), Ramachandran P (Office of CCA, MEITY, Govt of India), Rollin Yu (TrustAsia), Roman Fischer (SwissSign), Sandy Balzer (SwissSign), Scott Rea (eMudhra), Sissel Hoel (Buypass AS), Sooyoung Eo (NAVER Cloud Trust Services), Star Simmons (GoDaddy), Stephen Davidson (DigiCert), Sven Rajala (Keyfactor), Tadahiko Ito (SECOM Trust Systems), Thomas Zermeno (SSL.com), Tim Callan (Sectigo), Tim Hollebeek (DigiCert), Trevoli Ponds-White (Amazon), Tsung-Min Kuo (Chunghwa Telecom), V. Srinivasan (eMudhra), Vijayakumar (Vijay) Manjunatha (eMudhra), Yashwanth (eMudhra).

Preventing IPR conflicts when working with researchers

• Leader: Ben Wilson (Mozilla)
• Minutes: Tim Callan (Sectigo)
• Presentation link: Addressing IPR issues

Discussion outside the presentation:

Ben Wilson (Mozilla):

Goals: No royalties to implement CABF requirements We don’t go forward with anything encumbered by IP rights We don’t want to discourage sharing Transparency and notice of potential IP to engage in informed decision making

We had a major revision in 2018 to the IPR policy.

WGs will not approve of a guideline if essential claims exist that are not on royalty free terms.

An essential claim is where it’s essential to compliance that is in a patent where a claim of infringement may occur.

This narrows down what we’re really worried about, which is essential claims.

Patent holders that sign the IPR must disclose patents that have essential claims.

Everyone else is not bound. There could be someone who makes a contribution or suggestion that is encumbered by an IP right, and if we adopt a standard requiring it, there could be claims for royalties later.

Some ideas on how to proceed:

• Non IPR signers include speakers, invited guests, and GitHub contributors.
• Aaron Gable suggested than rather than having multiple agreements, we could have one agreement.
• We could present on GitHub, have the language in a speaker agreement, etc.
• We could stick to our guns and make everyone sign our IPR agreement.
• In the past, our experience was that people who resisted the IPR couldn’t go any further.
• We came to the point where we said, this is our IPR policy, take it or leave it.

Ideas:

• Contributor License Agreement
• Non-assertion pledge or agreement

For guest speakers could require a predisclosure of IP. Or they could be on notice without signing anything (which might not be legally binding).

Common terms:

1. Grant a license to contributions on royalty free terms
2. Promise not to assert patent claims against implementers or CABF

• How do we handle invited guests?

• How do we handle researchers?

• If they work for an entity, they are required to assign their patent to the entity. That is common practice.

[Ben shows the sample notice in the presentation.]

Additional suggestions include:

• Continuous improvement
• Documentation of agreements. Can we collect these in an automated way?

Dimitris (HARICA): In my two terms as chair I have received a lot of questions from candidate members about the IPR agreement. Also many invited guests. There have been challenges with Entrust, Identrust, and other members. We need to open the process of revising or reviewing the agreement to see if there are concerns. Look into what we see.

Tim Hollebeek (DigiCert): The IPR agreement is a peer-wise agreement among the members. We can’t do it by ballot. It’s a difficult process to update. Everyone’s legal department has to sign and we have to kick out anyone who does not.

Dimitris: Yes, and there needs to be a specific deadline. That’s why we don’t make changes too often. It is time to get our legal departments involved. If a company outside the forum has some kind of a patent and we introduce ideas in our guidelines that are protected by a non-member, how does that work?

Ben: We have to be aware of it. There is no duty on Siemens to notify us. In section 3.2.2.4, we have all these ways of doing things because that allows people alternatives. Because there are non-infringing methods of doing that.

Tim: When I pull for IPR concerns at ITF, I ask if the contributor has IP rights or is aware of anything. There needs to be a duty for members to notify the forum if they re aware of IPR they do not own.

Clint Wilson (Apple): I do think it’s a fair statement. My legal team has driven home with me that one aspect that some entities may not want to sign it because they do not want to give up their patents. That is a feature, not a bug. It depends on the changes we’re trying to make. I d ont’ think it’s a goal that everyone always be able to participate.

Dimitris: It’s not that we have an IPR policy for everyone to sign, but for the right reasons. If they have a patent and don’t want to disclose it. Usually they don’t know about all the IPR they have. Some companies don’t want to take the risk of saying they are not aware of a patent, but there might be a patent.

Clint: Yes, it’s a massive amount of work.

Trevoli Ponds-White (ATS): We skipped over Ben’s initial question. We first need to make a decision for people outside the forum, do we want to stick to our guns and make them sign the IPR agreement, or do we want to make it lighter? Let’s go back to that question first.

Dimitris: We exchanged some mails on that question. We identified two sources namely GitHub and guest speakers. Maybe the questions list. Other than that we feel like we have things under control. Ben has good ideas, but we need to process it and maybe run it past some of our legal teams.

Trev: If we feel like we need to get feedback, it feels like GitHub is how we should do it, with an agreement that it is submitted without license. For context, my suggestion is it would be good if we came up with guidelines for input from researchers for only those mechanisms. We should document to members understand how we accept contributions.

Tim: We need two things. Something lightweight for speakers, where it’s most likely a non-issue. When an external party not covered by the IPR is actively involved in drafting proposals or ballots, that is a very complicated situation and I don’t know how we fix it. That is a very dangerous situation.

Tobias Josefowitz (Opera): Not every possible contribution is toxic from an IPR perspective. Much of what’s on the list is simply no risk at all. For MPDV I think there could be exchange with researchers that has no risk at all. Where to we draw the line here?

Tim: Much like security, there is no such thing as no risk. But there are areas where we determine risk is acceptable, and we do this on a regular basis. But this is a complicated topic.

Ben: Regarding the Princeton MPDV process, I don’t think our existing agreements would have handled this, but I do think we handled it appropriately. Even though it’s outside of the IPR policy, it still is protecting us adequately.

Dim The point is we don’t want to get our legal teams involved. ETSI has an IPR policy, maybe we can compare to that.

Tim: There is nothing preventing Princeton from signing the current IPR agreement, Unless there is a blocking issue,

Dimitris: The scope it supposed to be at the WG level, not the forum level. If you don’t participate in a specific WG, you’re not affected by the IPR claims based on scope. This is not clear in the IPR agreement. For instance, if you don’t participate in Code Signing WG, you can claim any code signing patents you may have. But these organizations see it more broadly.

Ben: You’re saying we need to focus on making it easier for these organizations to sign the IPR agreement. We have defined essential claims. Only if they are aware of something we are doing that are essential claims, do they have to inform us.

Dimitris: Right now they think they need to ask all their subsidiaries if they have a patent associated with CABF.

Mrugesh Chandarana (IdenTrust): I agree. It’s impossible to do that checking.

Toby: I have two comments. For the Princeton researchers, there is a limited chance they would introduce anything into the final ballot that we couldn’t have introduced. So the situation is effectively the same. The likelihood that Princeton would make a claim that is affected by the ballot is roughly the same. I don’t think they’ll try to sneak something in that they have patented just to trick us. When it comes to the big corporations that can’t possibly check their IPR, they don’t have to. It’s a feature tha we get royalty free license. Otherwise they don’t have to participate. If that’s a problem for you, that’s their risk to take.

Trev: I want to echo what Tim was saying. If someone wants to join a WG, that’s what we have the IPR for. I want to make sure we separate the issues. We need guidance for the future and I want to make sure we solve it. Toby, I agree that it’s ridiculous that this is even an issue for Princeton.

Dim: Is this a big issue that is worth creating a subcommittee? The IPR is pretty serious.

Clint: If we’re talking bout revising the policy, we need a subcommittee. Let’s try to avoid that if possible, but if we must, let’s do it.

BR of BRs

• Leader: Paul van Brouwershaven (Entrust)
• Minutes: Ben Wilson (Mozilla)
• Presentation link: BR of BRs

Discussion outside the presentation:

The BRs of BRs is currently hosted at https://github.com/vanbroup/documents/tree/brofbr. Each guideline section is represented in a single, separate file. The BRs-of-Brs project proposes a layered approach starting with the BRs of BRs at the lowest layer, and then layered with network security, and then validation methods (DV, OV, and EV) layered above that. This is followed with certificate profile layers (TLS, S/MIME, Code Signing, etc.) above that. One possibility would be to have an auditor layer above all of those to include specifications that could be rendered into a document with special styling (e.g. Layers 800-899). And CAs could use Layers 900 to 999 to include control statements or CP/CPS language.

Update – Paul created a supporting interface (https://vanbroup.github.io/documents/), and a feature to compare similarities and differences among the documents. There are a lot of similarities among the documents. Of note, the S/MIME BRs have many improvements, but this means there are also many differences. However, on the whole there is much duplication. On average, 20-50% of the documents are the same, or they are 80% equivalent if you include the common elements. Also, not all section titles match up with RFC 3647. The intent is to eliminate duplication and add consistency to simplify adherence to and management of the requirements.

Paul was able to automatically render the TLS BRs using this method. He moved TLS-BR-specific sections to their own layer.

Dimitris noted that GitHub is very strict with white spaces, capitalization, etc. He also noted that it is difficult to identify the “meaningful” differences.

Paul demonstrated the UI and the comparison feature. You can look at the reasons why sections are different. To calculate the percentage of differences, he removes capitalization and line differences to get a truer view.

If we want to add language for TLS or Code Signing, an additional section would be added in the relevant layer to follow the existing text in the BRs of BRs.

Looking at similarities, Code Signing BRs says, “Abbreviations and Acronyms”, as it should according to RFC 3647. The TLS and S/MIME BR section titles don’t match RFC 3647.

This prep work allows us to go forward to the BRs of BRs without affecting the ongoing work on the guidelines. This process can be done with the EV Guidelines, too. The tool shows the difference between a version automatically generated (similarity between input file and output file).

The tool shows us what we need to correct in the TLS BRs to make capitalization, section titles, etc. uniform.

Dimitris said that our first step will be to use the tool to clean up capitalization, spacing, section titles, etc. among all of the CABF documents. Then we can focus on the more difficult differences.

Paul said a good first step is to start with the BRs-of-BRs layer.

Release notes can be automatically added, too.

Discussion items –

All documents will be based on the latest BRs.

Should the BRs of BRs be managed by a new, mandatory BRs of BRs working group (of all members) to address general PKI items? Specific concerns would be moved to the specific working group.

Should the validation subcommittee be a subgroup of a new BRs of BRs working group? (There may be IPR issues with this.)

Numbering scheme of RFC3647 needs to be determined for new subsections, and we can’t have conflicting subsection names.

Scott R. asked whether a mandatory WG creates IP issues if you don’t want to get involved with a particular topic / type of agreement. And how do you handle withdrawal?

Paul – there is an intent to avoid the IPR issues in the BRs of BRs WG. The focus should be on generic terms. Everything that would be discussed should have already been discussed in the specific working groups. Specific items should be discussed in the specific working groups.

Scott – but that might be a chicken-and-egg problem about where things are discussed.

Paul – yes, but we want to move forward and make everyone’s work more efficient.

Clint – I find the tools and the differences between the guidelines over time fascinating, but beyond that it is too early to go down the path of combining the documents into one. Participation in one WG shouldn’t obligate you to review the IP of everything.

Trev – the BRs of BRs should be of value, like if we had a Definitions WG.

Paul – maybe not everyone is required to be a member of the BRs of BRs WG.
That way, you are not declaring participation in the WG and any IP that might be implicated by that WG. Also, the S/MIME BRs were a wonderful development, but they did not get fed back into the Forum’s other documents.

Dimitris – Another way to look at this – each WG has a charter that defines the scope of the WG based on the type of certificate involved. And the charters all have a generic component in their scope. So, a member that is only part of the Server Certificate Working Group might not object to participating in the BRs of BRs WG for the generic aspect, but we need to be careful how we draft the scope in the charter. An alternative would be to have the server WG maintain that generic part, but that would be unfair to the other working groups.

Tim – another option is to have functional working groups that are more modular. They would be based on, e.g., validation, NetSec, etc. The tooling could help with this modularization. Also, if we review RFC 3647, it’s outdated. Section 3.2 is an example because different certificate types have different validation steps. We might want to modernize RFC 3647.

Paul – we could do WGs with narrower scopes. I would support it if it helps with the IPR discussion.

Tim – we should have a Validation WG

Paul – we need to start alignment with and among the existing working groups on the BRs of BRs baseline document. We need to be able to incorporate the suggestions of the other, non-SCWG WGs in that first baseline document. This needs to be discussed more here at the face-to-face meeting or online.

Dimitris – HARICA and Entrust could do an initial ballot to clean up the inconsistencies. We could get this done before the next F2F so that the numbers converge more.

Paul – do we need a new WG?

Dimitris – no, we don’t need a WG, we can proceed as currently structured.

Forum-level goals and plans for the remaining term

• Leader: Dimitris Zacharopoulos (HARICA), Paul van Brouwershaven (Entrust)
• Minutes: Arvid Vermote (GlobalSign)
• Presentation link: CA/B Forum 2022-2024 (update)

Discussion outside the presentation:

Dimitris has re-used the presentation from 3-4 F2F meetings ago when he and Paul set up a plan for the term 2022-2024. One remaining task that is pending is the review and alignment of working group charters, there is some divergence between charters (code signing / server cert working group). They want to analyze these changes and see if there is any common benefit to apply them to all.

The bylaws have been updated, increased consistency between forum ways of working. Tooling: minutes are working better and further improvement is underway, website has been enhanced and ballots and general ways of working have been improved through Github.

The topic of release cycles for Guidelines is still relevant, there is still a need to agree on specific release cycles but this requires changes to the bylaws (?). There is a proposal from Dimitris incoming in the next weeks on how to address / tackle this.

The control matrix for guidelines has been transformed to the BR of BR topic which is covered separately.

There are still a few open items 1) charter alignments 2) guidelines release cycles 3) additional method for elections (electronic voting), 4) BR of BRs, 5) ballot conflicts and 6) availability of recordings.

Specific for the recordings topic there were concerns raised related to confidentiality. Support for deleting the recordings after the minutes have been finalized seemed to be broad. Need to look at the retention period of the CABF webex accounts. There will be an attempt to integrate / automate this further through automatic e-mails.

Further open items 7) delegated third parties issue (and their audit schemes), 8) reviews based on incidents where the root causes were misunderstandings / misinterpretations of the BR, 9) IPR review periods (concerns were raised related to the new timing / deadline proposals being punitive and not providing any constructive resolve). The IPR review period topic will be dropped based on the feedback provided.

Definitions and Glossary WG

• Leader: Clint Wilson (Apple), Tim Hollebeek (DigiCert)
• Minutes: Corey Bonell (DigiCert)
• Presentation link:

Discussion outside the presentation:

Tim provided the motivation for the creation of this Working Group. The definitions are cross-referential and even have circular references. Cleaning the intertwined mess is a priority. The initial focus is not to refine the definitions themselves.

It is proposed that Tim Hollebeek will Chair and Tim Callan will co-Chair the group.

Currently, there is a charter for this Working Group. We would like to move the ballot for the creation of this group forward.

Clint presented the changes to the proposed Charter in Github: https://github.com/cabforum/forum/pull/33. Tim C. asked how we will remove or deadline for group shutdown. Clint said that the Charter can be amended if needed. Tim C. said that he foresees that we will need to extend the deadline for shutdown perpetually due to ongoing changes, but it can be revisited later.

Tim H. said that the formation of a definitions document from this group is a step towards the overall BR of BRs. Dimitris asked if this group will tackle only the shared definitions across documents, or will it include all definitions. Clint said the group can tackle all definitions, but the group will need to prioritize the work.

Dimitris raised a concern about definitions containing normative requirements and how this group will resolve this issue. He raised the Defined Term “Authorization Domain Name” in the TLSBRs. Tim said that the removal of requirements from definitions is an explicit goal of the group. Clint agreed and said that the removal of normative requirements will require other working groups to define these requirements elsewhere within their constituent documents. Tim also said the group will need to be aware of definitions that are specific to a single document.

Martijn raised a concern that it may be difficult to entirely remove requirements from definitions. Tim C. said that if definitions contain requirements, we will need to be careful in authoring these definitions.

Aaron Poulsen when the first meeting will occur. Clint said that will happen once the ballot creating the group passing, possibly in April. Inigo asked the meeting cadence. Tim H. suggested one meeting every two weeks.

Nicol So said it would be beneficial in identifying best practices in authoring definitions. Tim C. said that we may want to encourage working groups to not create definitions within their own group but rather approach this group to author the definition. Tim H. said that we should leverage existing industry terminology as much as possible.

ADJURNED Forum Plenary Meeting for Day 2