Welcome to the CA/Browser Forum
The Certification Authority Browser Forum (CA/Browser Forum) is a voluntary gathering of Certificate Issuers and suppliers of Internet browser software and other applications that use certificates (Certificate Consumers).
More information for about the forum and information for Site Owners, Developers, Auditors and Assessors, and Potential Members can be found in the About section of this website.
Recent posts
Ballot SC105: Remove High Risk language from TLS BR and EVG
October 28, 2026 by Voting Results Certificate Issuers 27 votes in total:
October 28, 2026 by Voting Results Certificate Issuers 27 votes in total:
2026-10-22 Minutes of the Server Certificate Working Group
October 22, 2026 by Wayne ThayerServer Certificate Working Group Meeting — 2026-10-22 MinutesMinutes 1. Opening Dimitris Zacharopoulos (HARICA) chaired the meeting. The meeting was recorded, roll call was taken via Webex, and the Note Well was read: all participants are reminded that they must comply with the CA/Browser Forum’s Bylaws, which include an Antitrust Policy, a Code of Conduct, and an Intellectual Property Rights Agreement. No changes were made to the published agenda. The face-to-face follow-up topics from Google Chrome were deferred prior to the call. 2. Minutes Approval The minutes of the September 23, 2026 Face-to-Face #68 (Vienna) meeting were approved without objection. Dimitris Zacharopoulos (HARICA) will coordinate with Wayne Thayer (Fastly) to upload the face-to-face presentations from the wiki to GitHub for publication on the website. The minutes of the October 8, 2026 teleconference have not been distributed yet. Eva Van Steenberge (GlobalSign) noted in chat that they will be distributed shortly. 3. Membership Applications GeeRoam Information Technology Co., Ltd. applied for membership as an Interested Party. Dean Coclin (DigiCert) confirmed that the company seal was included on the official signing paperwork. Outcome: GeeRoam Information Technology Co., Ltd. was approved as an Interested Party without objection. 4. ECDSA Key Size Requirements in the BRs Dimitris Zacharopoulos (HARICA) raised a recent incident involving ECDSA intermediate certificates with weak keys. He noted that while Section 6.1.6 of the TLS BRs specifies quality checks for RSA keys, there are no explicit minimum checks for weak ECDSA private scalars, and proposed drafting a ballot to address the gap. He also noted that Aaron Gable (ISRG) contributed a lint to ZLint for small private scalars. Aaron Gable (ISRG) supported a ballot and noted: His ZLint contribution used 256 (1 byte) as an arbitrary cutoff for small private scalars, comparable to the 752 cutoff for RSA factors. While batch attacks can check scalars up to 2^32 in 2^16 operations, running 2^16 operations per individual Subscriber key may be too slow for CAs. Changing the NIST SP 800-56A SHOULD to SHALL would not address this issue, because public keys derived from small scalars are still valid curve points. Adding an explicit check is preferable to relying on the general “well-known attacks” clause. Trevoli Ponds-White (Amazon Trust Services) noted that the requirements should explicitly specify when the check must occur (i.e., prior to signing). Aaron Gable (ISRG) also highlighted a structural gap in Section 6.1.1: Section 6.1.1.1 covers CA key generation and Section 6.1.1.3 covers rejecting weak Subscriber keys, leaving a gap when a CA generates a weak key or cross-signs a Subordinate CA CSR. He suggested consolidating Section 6.1.1 so that key quality checks (Debian weak keys, ROCA, close primes, Fermat, small private scalars, etc.) must be performed on all CA and Subscriber keys prior to signing. Dimitris Zacharopoulos (HARICA) agreed and will work on draft ballot text for discussion on the public list. 5. Ballot Status In Discussion Period:
October 22, 2026 by Wayne ThayerServer Certificate Working Group Meeting — 2026-10-22 MinutesMinutes 1. Opening Dimitris Zacharopoulos (HARICA) chaired the meeting. The meeting was recorded, roll call was taken via Webex, and the Note Well was read: all participants are reminded that they must comply with the CA/Browser Forum’s Bylaws, which include an Antitrust Policy, a Code of Conduct, and an Intellectual Property Rights Agreement. No changes were made to the published agenda. The face-to-face follow-up topics from Google Chrome were deferred prior to the call. 2. Minutes Approval The minutes of the September 23, 2026 Face-to-Face #68 (Vienna) meeting were approved without objection. Dimitris Zacharopoulos (HARICA) will coordinate with Wayne Thayer (Fastly) to upload the face-to-face presentations from the wiki to GitHub for publication on the website. The minutes of the October 8, 2026 teleconference have not been distributed yet. Eva Van Steenberge (GlobalSign) noted in chat that they will be distributed shortly. 3. Membership Applications GeeRoam Information Technology Co., Ltd. applied for membership as an Interested Party. Dean Coclin (DigiCert) confirmed that the company seal was included on the official signing paperwork. Outcome: GeeRoam Information Technology Co., Ltd. was approved as an Interested Party without objection. 4. ECDSA Key Size Requirements in the BRs Dimitris Zacharopoulos (HARICA) raised a recent incident involving ECDSA intermediate certificates with weak keys. He noted that while Section 6.1.6 of the TLS BRs specifies quality checks for RSA keys, there are no explicit minimum checks for weak ECDSA private scalars, and proposed drafting a ballot to address the gap. He also noted that Aaron Gable (ISRG) contributed a lint to ZLint for small private scalars. Aaron Gable (ISRG) supported a ballot and noted: His ZLint contribution used 256 (1 byte) as an arbitrary cutoff for small private scalars, comparable to the 752 cutoff for RSA factors. While batch attacks can check scalars up to 2^32 in 2^16 operations, running 2^16 operations per individual Subscriber key may be too slow for CAs. Changing the NIST SP 800-56A SHOULD to SHALL would not address this issue, because public keys derived from small scalars are still valid curve points. Adding an explicit check is preferable to relying on the general “well-known attacks” clause. Trevoli Ponds-White (Amazon Trust Services) noted that the requirements should explicitly specify when the check must occur (i.e., prior to signing). Aaron Gable (ISRG) also highlighted a structural gap in Section 6.1.1: Section 6.1.1.1 covers CA key generation and Section 6.1.1.3 covers rejecting weak Subscriber keys, leaving a gap when a CA generates a weak key or cross-signs a Subordinate CA CSR. He suggested consolidating Section 6.1.1 so that key quality checks (Debian weak keys, ROCA, close primes, Fermat, small private scalars, etc.) must be performed on all CA and Subscriber keys prior to signing. Dimitris Zacharopoulos (HARICA) agreed and will work on draft ballot text for discussion on the public list. 5. Ballot Status In Discussion Period:
2026-10-21 Minutes of the S/MIME Certificate Working Group
October 21, 2026 by Minutes of SMCWG October 21, 2026 These are the Minutes of the meeting described in the subject of this message. Corrections and clarifications where needed are encouraged by reply.
More posts of the CA/Browser ForumOctober 21, 2026 by Minutes of SMCWG October 21, 2026 These are the Minutes of the meeting described in the subject of this message. Corrections and clarifications where needed are encouraged by reply.