Voting Period Begins: Ballot SC-101v2: Clarify Authorization Domain Names
542 views
Skip to first unread message
Aaron Gable
Jun 23, 2026, 7:19:17 PMJun 23
to server...@groups.cabforum.org, Rich Smith, Chris Clements
Ballot SC-101v2: Clarify Authorization Domain Names
Summary of the Ballot
In Section 3.2.2.4, explicitly describe the algorithm by which a CA may derive an Authorization Domain Name from an applied-for FQDN. The algorithm described is consistent with the most common interpretation of the current definition of ADN, so this is not expected to be a disruptive change for most CAs, but it removes ambiguity and closes one security issue (described below).
Simplify the definition of Authorization Domain Name to be merely descriptive. Update all validation methods to describe how they validate control of the selected ADN. Collapse all previous statements about validation method suitability for wildcard and ending-in-the-same-suffix validation into a table in Section 3.2.2.4. As a knock-on effect, simplify the definitions of Base Domain Name and Domain Contact.
Although these changes are simple, they are also sweeping. As such, the ballot includes a provision that CAs may comply with Section 3.2.2.4 of the previous version of the Baseline Requirements until November 15, 2026. This is derived from the approach taken by v2.0 of the Network Security Requirements.
Background of the Ballot
The existing definition of Authorization Domain Name has two severe issues:
a) It contains normative policy language (describing how to derive an ADN) but attempts to be a concise and descriptive definition, leading to ambiguity as to whether parts of the definition can be performed exclusively, in sequence, repeatedly, or otherwise.
b) Under some interpretations, it allows for issuance of certificates for names over which the applicant has not demonstrated any control.
Specifically, one interpretation of the current definition of an ADN is that a CA may prune labels from the left-hand side of the FQDN, then follow one or more CNAMEs, and then use the resulting FQDN as the ADN. However, just because `example.com` has a CNAME pointing to `example.org`, that does not give the operators of `example.org` any control over subdomains of such as `blog.example.com`. Under this interpretation, an entity capable of demonstrating control of a CNAME (such as a CDN operator) might be able to get issuance of certificates for arbitrary subdomains of names that are CNAMEd to them. This is not good.
This ballot resolves the issue by much more strictly describing the acceptable ADN derivation algorithm. In particular:
- The ADN must be selected after the validation method has been selected.
- Only certain methods (those which perform validation at the name itself, not at a underscore-prefixed subdomain of it) can use the "cname" step of the ADN algorithm.
- Only certain methods (those which currently allow issuance for "other FQDNs that end with all the Domain Labels of the validated FQDN") can use the "prune" step of the ADN algorithm.
- Following CNAMEs must happen before pruning labels, if both operations are performed.
This makes it much easier for CAs to implement provably-compliant ADN derivation algorithms, and closes the security hole described above.
This ballot also explicitly acknowledges something that has always been true: that all validation methods are in fact validating control over the ADN, not the applied-for FQDN (unless the CA has selected the ADN to be exactly equal to the applied-for FQDN). This means that validation data reuse also works at the ADN level: if two applied-for FQDNs can both be turned into the same ADN, then demonstrating control of that ADN is valid for the issuance of both applied-for FQDNs.
This ballot differs from the original SC-101 in only one substantive way: it adds an effective date for the change to Section 3.2.2.5.3, which is not covered by the general effective date covering all of Section 3.2.2.4. The other changes are merely editorial. You can see a diff from SC-101 to SC-101v2 here.
The following motion is proposed by Aaron Gable (Let's Encrypt / ISRG) and endorsed by Rich Smith (DigiCert) and Chris Clements (Google).
--- Motion Begins ---
Modify the "Baseline Requirements for the Issuance and Management of Publicly-Trusted Server Certificates", based on Version 2.2.7, per the following redline:
--- Motion Ends ---
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (at least 7 days):
- Start time: 2026-06-12 17:00 UTC
- End time: 2026-06-19 17:00 UTC or later
Vote for approval (7 days):
- Start time: 2026-06-23 23:20 UTC
- End time: 2026-06-30 23:20 UTC
黃晟(orca)
Jun 23, 2026, 11:54:59 PMJun 23
to server...@groups.cabforum.org, Rich Smith, Chris Clements
TWCA votes Yes on Ballot SC-101v2.
Best,
Sean Huang
Senior PKI Compliance Engineer
TEL：02-2370-8886#728
FAX：02-2388-6720
Email：or...@twca.com.tw
10F., No. 85, Yanping South Road,
Taipei, Taiwan (R.O.C.)
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
servercert-w...@groups.cabforum.org.
To view this discussion visit
https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAEmnErcv%2Bs4-YRDx8F31j1HMtrxnVQLQCZs3ifO2KxNvQVouTA%40mail.gmail.com.
Hogeun Yoo
Jun 24, 2026, 12:41:03 AMJun 24
to server...@groups.cabforum.org
NAVER Cloud Trust Services votes "Yes" on Ballot SC-101v2.
Regards,
Hogeun Yoo
-----Original Message-----
From: "'Aaron Gable' via Server Certificate WG (CA/B Forum)"<server...@groups.cabforum.org>
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAEmnErcv%2Bs4-YRDx8F31j1HMtrxnVQLQCZs3ifO2KxNvQVouTA%40mail.gmail.com.
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAEmnErcv%2Bs4-YRDx8F31j1HMtrxnVQLQCZs3ifO2KxNvQVouTA%40mail.gmail.com.
jun....@cybertrust.co.jp
Jun 24, 2026, 3:56:03 AMJun 24
to server...@groups.cabforum.org, rich....@digicert.com, ccle...@google.com
Cybertrust Japan votes Yes on Ballot SC-101v2.
-----Original Message-----
From: 'Aaron Gable' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Wednesday, June 24, 2026 8:19 AM
To: server...@groups.cabforum.org
Cc: Rich Smith <rich....@digicert.com>; Chris Clements <ccle...@google.com>
This ballot resolves the issue by much more strictly describing the acceptable ADN derivation algorithm. In particular:
- The ADN must be selected after the validation method has been selected.
- Only certain methods (those which perform validation at the name itself, not at a underscore-prefixed subdomain of it) can use the "cname" step of the ADN algorithm.
- Only certain methods (those which currently allow issuance for "other FQDNs that end with all the Domain Labels of the validated FQDN") can use the "prune" step of the ADN algorithm.
- Following CNAMEs must happen before pruning labels, if both operations are performed.
This makes it much easier for CAs to implement provably-compliant ADN derivation algorithms, and closes the security hole described above.
This ballot also explicitly acknowledges something that has always been true: that all validation methods are in fact validating control over the ADN, not the applied-for FQDN (unless the CA has selected the ADN to be exactly equal to the applied-for FQDN). This means that validation data reuse also works at the ADN level: if two applied-for FQDNs can both be turned into the same ADN, then demonstrating control of that ADN is valid for the issuance of both applied-for FQDNs.
This ballot differs from the original SC-101 in only one substantive way: it adds an effective date for the change to Section 3.2.2.5.3, which is not covered by the general effective date covering all of Section 3.2.2.4. The other changes are merely editorial. You can see a diff from SC-101 to SC-101v2 here <https://github.com/cabforum/servercert/pull/627/changes/709bb8f4460b1743a7df5f1bf0c728a496c57e4a..0a66f1dfad21cc9964738ce753b5ac8859d9a265> .
The following motion is proposed by Aaron Gable (Let's Encrypt / ISRG) and endorsed by Rich Smith (DigiCert) and Chris Clements (Google).
--- Motion Begins ---
Modify the "Baseline Requirements for the Issuance and Management of Publicly-Trusted Server Certificates", based on Version 2.2.7, per the following redline:
https://github.com/cabforum/servercert/compare/1bcb34993331313c92ac7d6af778e81ca3d5faff...0a66f1dfad21cc9964738ce753b5ac8859d9a265
--- Motion Ends ---
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (at least 7 days):
* Start time: 2026-06-12 17:00 UTC
* End time: 2026-06-19 17:00 UTC or later
Vote for approval (7 days):
* Start time: 2026-06-23 23:20 UTC
* End time: 2026-06-30 23:20 UTC
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org <mailto:servercert-w...@groups.cabforum.org> .
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAEmnErcv%2Bs4-YRDx8F31j1HMtrxnVQLQCZs3ifO2KxNvQVouTA%40mail.gmail.com <https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAEmnErcv%2Bs4-YRDx8F31j1HMtrxnVQLQCZs3ifO2KxNvQVouTA%40mail.gmail.com?utm_medium=email&utm_source=footer> .
-----Original Message-----
From: 'Aaron Gable' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Wednesday, June 24, 2026 8:19 AM
To: server...@groups.cabforum.org
Cc: Rich Smith <rich....@digicert.com>; Chris Clements <ccle...@google.com>
Subject: [Servercert-wg] Voting Period Begins: Ballot SC-101v2: Clarify Authorization Domain Names
Ballot SC-101v2: Clarify Authorization Domain Names
Summary of the Ballot
In Section 3.2.2.4, explicitly describe the algorithm by which a CA may derive an Authorization Domain Name from an applied-for FQDN. The algorithm described is consistent with the most common interpretation of the current definition of ADN, so this is not expected to be a disruptive change for most CAs, but it removes ambiguity and closes one security issue (described below).
Simplify the definition of Authorization Domain Name to be merely descriptive. Update all validation methods to describe how they validate control of the selected ADN. Collapse all previous statements about validation method suitability for wildcard and ending-in-the-same-suffix validation into a table in Section 3.2.2.4. As a knock-on effect, simplify the definitions of Base Domain Name and Domain Contact.
Although these changes are simple, they are also sweeping. As such, the ballot includes a provision that CAs may comply with Section 3.2.2.4 of the previous version of the Baseline Requirements until November 15, 2026. This is derived from the approach taken by v2.0 of the Network Security Requirements.
Background of the Ballot
The existing definition of Authorization Domain Name has two severe issues:
a) It contains normative policy language (describing how to derive an ADN) but attempts to be a concise and descriptive definition, leading to ambiguity as to whether parts of the definition can be performed exclusively, in sequence, repeatedly, or otherwise.
b) Under some interpretations, it allows for issuance of certificates for names over which the applicant has not demonstrated any control.
Specifically, one interpretation of the current definition of an ADN is that a CA may prune labels from the left-hand side of the FQDN, then follow one or more CNAMEs, and then use the resulting FQDN as the ADN. However, just because `example.com <http://example.com/> ` has a CNAME pointing to `example.org <http://example.org/> `, that does not give the operators of `example.org <http://example.org/> ` any control over subdomains of such as `blog.example.com <http://blog.example.com/> `. Under this interpretation, an entity capable of demonstrating control of a CNAME (such as a CDN operator) might be able to get issuance of certificates for arbitrary subdomains of names that are CNAMEd to them. This is not good.
Ballot SC-101v2: Clarify Authorization Domain Names
Summary of the Ballot
In Section 3.2.2.4, explicitly describe the algorithm by which a CA may derive an Authorization Domain Name from an applied-for FQDN. The algorithm described is consistent with the most common interpretation of the current definition of ADN, so this is not expected to be a disruptive change for most CAs, but it removes ambiguity and closes one security issue (described below).
Simplify the definition of Authorization Domain Name to be merely descriptive. Update all validation methods to describe how they validate control of the selected ADN. Collapse all previous statements about validation method suitability for wildcard and ending-in-the-same-suffix validation into a table in Section 3.2.2.4. As a knock-on effect, simplify the definitions of Base Domain Name and Domain Contact.
Although these changes are simple, they are also sweeping. As such, the ballot includes a provision that CAs may comply with Section 3.2.2.4 of the previous version of the Baseline Requirements until November 15, 2026. This is derived from the approach taken by v2.0 of the Network Security Requirements.
Background of the Ballot
The existing definition of Authorization Domain Name has two severe issues:
a) It contains normative policy language (describing how to derive an ADN) but attempts to be a concise and descriptive definition, leading to ambiguity as to whether parts of the definition can be performed exclusively, in sequence, repeatedly, or otherwise.
b) Under some interpretations, it allows for issuance of certificates for names over which the applicant has not demonstrated any control.
This ballot resolves the issue by much more strictly describing the acceptable ADN derivation algorithm. In particular:
- The ADN must be selected after the validation method has been selected.
- Only certain methods (those which perform validation at the name itself, not at a underscore-prefixed subdomain of it) can use the "cname" step of the ADN algorithm.
- Only certain methods (those which currently allow issuance for "other FQDNs that end with all the Domain Labels of the validated FQDN") can use the "prune" step of the ADN algorithm.
- Following CNAMEs must happen before pruning labels, if both operations are performed.
This makes it much easier for CAs to implement provably-compliant ADN derivation algorithms, and closes the security hole described above.
This ballot also explicitly acknowledges something that has always been true: that all validation methods are in fact validating control over the ADN, not the applied-for FQDN (unless the CA has selected the ADN to be exactly equal to the applied-for FQDN). This means that validation data reuse also works at the ADN level: if two applied-for FQDNs can both be turned into the same ADN, then demonstrating control of that ADN is valid for the issuance of both applied-for FQDNs.
The following motion is proposed by Aaron Gable (Let's Encrypt / ISRG) and endorsed by Rich Smith (DigiCert) and Chris Clements (Google).
--- Motion Begins ---
Modify the "Baseline Requirements for the Issuance and Management of Publicly-Trusted Server Certificates", based on Version 2.2.7, per the following redline:
https://github.com/cabforum/servercert/compare/1bcb34993331313c92ac7d6af778e81ca3d5faff...0a66f1dfad21cc9964738ce753b5ac8859d9a265
--- Motion Ends ---
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (at least 7 days):
* End time: 2026-06-19 17:00 UTC or later
Vote for approval (7 days):
* End time: 2026-06-30 23:20 UTC
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAEmnErcv%2Bs4-YRDx8F31j1HMtrxnVQLQCZs3ifO2KxNvQVouTA%40mail.gmail.com <https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAEmnErcv%2Bs4-YRDx8F31j1HMtrxnVQLQCZs3ifO2KxNvQVouTA%40mail.gmail.com?utm_medium=email&utm_source=footer> .
Aaron Gable
Jun 24, 2026, 12:44:43 PMJun 24
to server...@groups.cabforum.org
Let's Encrypt / ISRG votes Yes on Ballot SC-101v2.
Ben Wilson
Jun 24, 2026, 1:27:12 PMJun 24
to server...@groups.cabforum.org
Mozilla votes "Yes" on Ballot SC-101v2.
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAEmnErcv%2Bs4-YRDx8F31j1HMtrxnVQLQCZs3ifO2KxNvQVouTA%40mail.gmail.com.
Wayne Thayer
Jun 24, 2026, 10:58:57 PMJun 24
to server...@groups.cabforum.org
Fastly votes "Yes" on Ballot SC-101v2.
- Wayne
--
Dimitris Zacharopoulos (HARICA)
Jun 25, 2026, 1:01:35 AMJun 25
to 'Aaron Gable' via Server Certificate WG (CA/B Forum)
HARICA votes "yes" to ballot SC101v2.
Tugba ÖZCAN (BILGEM KSM)
Jun 25, 2026, 2:22:01 AMJun 25
to servercert-wg, Rich Smith, Chris Clements
Kamu SM votes Yes on Ballot SC-101v2.
Tuğba ÖZCAN
TÜBİTAK BİLGEM
TÜBİTAK BİLGEM
Kamu Sertifikasyon Merkezi/E-İmza Teknolojileri Birim Yöneticisi
Kimden: "'Aaron Gable' via Server Certificate WG (CA/B Forum)" <server...@groups.cabforum.org>
Kime: "servercert-wg" <server...@groups.cabforum.org>
Kk: "Rich Smith" <rich....@digicert.com>, "Chris Clements" <ccle...@google.com>
Gönderilenler: 24 Haziran Çarşamba 2026 2:19:01
Konu: [Servercert-wg] Voting Period Begins: Ballot SC-101v2: Clarify Authorization Domain Names
Kime: "servercert-wg" <server...@groups.cabforum.org>
Kk: "Rich Smith" <rich....@digicert.com>, "Chris Clements" <ccle...@google.com>
Gönderilenler: 24 Haziran Çarşamba 2026 2:19:01
Konu: [Servercert-wg] Voting Period Begins: Ballot SC-101v2: Clarify Authorization Domain Names
--
Scott Rea
Jun 25, 2026, 8:13:17 AMJun 25
to server...@groups.cabforum.org, Rich Smith, Chris Clements
eMudhra Votes Yes to Ballot SC-101v2
From: 'Aaron Gable' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Tuesday, 23 June 2026 at 5:19 PM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Cc: Rich Smith <rich....@digicert.com>; Chris Clements <ccle...@google.com>
Date: Tuesday, 23 June 2026 at 5:19 PM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Cc: Rich Smith <rich....@digicert.com>; Chris Clements <ccle...@google.com>
Subject: [Servercert-wg] Voting Period Begins: Ballot SC-101v2: Clarify Authorization Domain Names
|
CAUTION: This email is originated from outside of the organization. Do not open the links or the attachments unless you recognize the sender and know the content is safe.
|
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAEmnErcv%2Bs4-YRDx8F31j1HMtrxnVQLQCZs3ifO2KxNvQVouTA%40mail.gmail.com.
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAEmnErcv%2Bs4-YRDx8F31j1HMtrxnVQLQCZs3ifO2KxNvQVouTA%40mail.gmail.com.
Disclaimer: The email and its contents hold confidential information and are intended for the person or entity to which it is addressed. If you are not the intended recipient, please note that any distribution or copying of this email is strictly prohibited
as per Company Policy, you are requested to notify the sender and delete the email and associated attachments with it from your system.
Trevoli Ponds-White
Jun 25, 2026, 11:20:02 AMJun 25
to Server Certificate WG (CA/B Forum), aa...@letsencrypt.org, Rich Smith, ccle...@google.com
Amazon Trust Services votes yes.
Dustin Hollenback
Jun 25, 2026, 11:41:39 AMJun 25
to server...@groups.cabforum.org
Apple votes “yes” on SC-101v2.
Nome Huang
Jun 25, 2026, 11:26:04 PMJun 25
to Server Certificate WG (CA/B Forum), aa...@letsencrypt.org, Rich Smith, ccle...@google.com
TrustAsia votes "Yes" on Ballot SC-101v2.
sde...@godaddy.com
Jun 26, 2026, 10:32:31 AMJun 26
to server...@groups.cabforum.org
GoDaddy votes Yes on Ballot SC-101v2.
Regards,
Steven Deitte
From: 'Aaron Gable' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Tuesday, June 23, 2026 at 7:19 PM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Cc: Rich Smith <rich....@digicert.com>; Chris Clements <ccle...@google.com>
Date: Tuesday, June 23, 2026 at 7:19 PM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Cc: Rich Smith <rich....@digicert.com>; Chris Clements <ccle...@google.com>
Subject: [Servercert-wg] Voting Period Begins: Ballot SC-101v2: Clarify Authorization Domain Names
This Message Is From an External Sender
This message came from outside your organization.
Ryan Dickson
Jun 26, 2026, 11:24:45 AMJun 26
to server...@groups.cabforum.org
Google votes "Yes" on Ballot SC-101v2.
--
Tim Hollebeek
Jun 26, 2026, 11:42:18 AMJun 26
to Server Certificate WG (CA/B Forum), aa...@letsencrypt.org, Rich Smith, ccle...@google.com
DigiCert votes YES on SC-101v2.
-Tim
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
Andrea Holland
Jun 26, 2026, 4:09:30 PMJun 26
to server...@groups.cabforum.org
IdenTrust votes Yes to SC-101v2
Sincerely,
Andrea Holland
From: 'Aaron Gable' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Tuesday, June 23, 2026 7:19 PM
To: server...@groups.cabforum.org
Cc: Rich Smith <rich....@digicert.com>; Chris Clements <ccle...@google.com>
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
servercert-w...@groups.cabforum.org.
성지은 Jieun Seong
Jun 29, 2026, 2:34:26 AMJun 29
to Aaron Gable via Server Certificate WG (CA/B Forum), 윤현중, 서연지
Government of Korea "YES" on Ballot SC-101v2.
Jieun Seong
Researcher / Dept of Digital Authentication
Korea Local Information Research & Development Institute, KLID
301, Seongam-ro, Mapo-gu, Seoul, 03923, Korea
D: +82 (2) 2031-9418 / M: +82 (10) 4800 0224
Date: 2026/06/24 08:25:07
From: "'Aaron Gable' via Server Certificate WG (CA/B Forum)"
To: "server...@groups.cabforum.org"
Cc: Rich Smith , Chris Clements
Subject: [Servercert-wg] Voting Period Begins: Ballot SC-101v2: Clarify Authorization Domain Names
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAEmnErcv%2Bs4-YRDx8F31j1HMtrxnVQLQCZs3ifO2KxNvQVouTA%40mail.gmail.com.
大野 文彰
Jun 29, 2026, 5:48:39 AMJun 29
to server...@groups.cabforum.org, Rich Smith, Chris Clements
SECOM Trust Systems votes YES on Ballot SC-101v2.
Best regards,
ONO Fumiaki / 大野 文彰
(Japanese name order: family name first, in uppercase)
SECOM Trust Systems CO., LTD.
From: 'Aaron Gable' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Wednesday, June 24, 2026 8:19 AM
--
Pedro FUENTES
Jun 29, 2026, 5:58:48 AMJun 29
to server...@groups.cabforum.org
OISTE Votes Yes to SC-101v2
-----Original Message-----
From: 'Aaron Gable' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Wednesday, June 24, 2026 8:19 AM
To: server...@groups.cabforum.org
Cc: Rich Smith <https://urldefense.proofpoint.com/v2/url?u=http-3A__rich.smith-40digicert.com&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AFTYu1HAQdkStwzgxyDbKOLyDwTHEezL5yeqoxeZ0fc&m=YHD2SfBbnT6AYDCLfiEzPPKkbhi1m9JR8pMLc3pp39vqM1wjkv2IWS_58TgRDgoG&s=AhAI8cWo9swaYIRBGMrxysAmuRVeyRhiQRgNINVlicw&e=>; Chris Clements <ccle...@google.com>
Subject: [Servercert-wg] Voting Period Begins: Ballot SC-101v2: Clarify Authorization Domain Names
Ballot SC-101v2: Clarify Authorization Domain Names
Summary of the Ballot
In Section 3.2.2.4, explicitly describe the algorithm by which a CA may derive an Authorization Domain Name from an applied-for FQDN. The algorithm described is consistent with the most common interpretation of the current definition of ADN, so this is not expected to be a disruptive change for most CAs, but it removes ambiguity and closes one security issue (described below).
Simplify the definition of Authorization Domain Name to be merely descriptive. Update all validation methods to describe how they validate control of the selected ADN. Collapse all previous statements about validation method suitability for wildcard and ending-in-the-same-suffix validation into a table in Section 3.2.2.4. As a knock-on effect, simplify the definitions of Base Domain Name and Domain Contact.
Although these changes are simple, they are also sweeping. As such, the ballot includes a provision that CAs may comply with Section 3.2.2.4 of the previous version of the Baseline Requirements until November 15, 2026. This is derived from the approach taken by v2.0 of the Network Security Requirements.
Background of the Ballot
The existing definition of Authorization Domain Name has two severe issues:
a) It contains normative policy language (describing how to derive an ADN) but attempts to be a concise and descriptive definition, leading to ambiguity as to whether parts of the definition can be performed exclusively, in sequence, repeatedly, or otherwise.
b) Under some interpretations, it allows for issuance of certificates for names over which the applicant has not demonstrated any control.
Specifically, one interpretation of the current definition of an ADN is that a CA may prune labels from the left-hand side of the FQDN, then follow one or more CNAMEs, and then use the resulting FQDN as the ADN. However, just because `example.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com_&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AFTYu1HAQdkStwzgxyDbKOLyDwTHEezL5yeqoxeZ0fc&m=YHD2SfBbnT6AYDCLfiEzPPKkbhi1m9JR8pMLc3pp39vqM1wjkv2IWS_58TgRDgoG&s=0NzGJchaenQtFS4k3xWrX2ZRQujAyYbCEg8QGoiQzWI&e=> ` has a CNAME pointing to `example.org <https://urldefense.proofpoint.com/v2/url?u=http-3A__example.org_&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AFTYu1HAQdkStwzgxyDbKOLyDwTHEezL5yeqoxeZ0fc&m=YHD2SfBbnT6AYDCLfiEzPPKkbhi1m9JR8pMLc3pp39vqM1wjkv2IWS_58TgRDgoG&s=Zf-nDNJsTKTVs3YyLNO6Ll_a3dWVGWYnklKU18Jc39M&e=> `, that does not give the operators of `example.org <https://urldefense.proofpoint.com/v2/url?u=http-3A__example.org_&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AFTYu1HAQdkStwzgxyDbKOLyDwTHEezL5yeqoxeZ0fc&m=YHD2SfBbnT6AYDCLfiEzPPKkbhi1m9JR8pMLc3pp39vqM1wjkv2IWS_58TgRDgoG&s=Zf-nDNJsTKTVs3YyLNO6Ll_a3dWVGWYnklKU18Jc39M&e=> ` any control over subdomains of such as `blog.example.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.example.com_&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AFTYu1HAQdkStwzgxyDbKOLyDwTHEezL5yeqoxeZ0fc&m=YHD2SfBbnT6AYDCLfiEzPPKkbhi1m9JR8pMLc3pp39vqM1wjkv2IWS_58TgRDgoG&s=Z-FmX1KTrK3_q54U9ZnRAXurfXBaLyz-Yu5HjawP1Z0&e=> `. Under this interpretation, an entity capable of demonstrating control of a CNAME (such as a CDN operator) might be able to get issuance of certificates for arbitrary subdomains of names that are CNAMEd to them. This is not good.
This ballot resolves the issue by much more strictly describing the acceptable ADN derivation algorithm. In particular:
- The ADN must be selected after the validation method has been selected.
- Only certain methods (those which perform validation at the name itself, not at a underscore-prefixed subdomain of it) can use the "cname" step of the ADN algorithm.
- Only certain methods (those which currently allow issuance for "other FQDNs that end with all the Domain Labels of the validated FQDN") can use the "prune" step of the ADN algorithm.
- Following CNAMEs must happen before pruning labels, if both operations are performed.
This makes it much easier for CAs to implement provably-compliant ADN derivation algorithms, and closes the security hole described above.
This ballot also explicitly acknowledges something that has always been true: that all validation methods are in fact validating control over the ADN, not the applied-for FQDN (unless the CA has selected the ADN to be exactly equal to the applied-for FQDN). This means that validation data reuse also works at the ADN level: if two applied-for FQDNs can both be turned into the same ADN, then demonstrating control of that ADN is valid for the issuance of both applied-for FQDNs.
This ballot differs from the original SC-101 in only one substantive way: it adds an effective date for the change to Section 3.2.2.5.3, which is not covered by the general effective date covering all of Section 3.2.2.4. The other changes are merely editorial. You can see a diff from SC-101 to SC-101v2 here <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_cabforum_servercert_pull_627_changes_709bb8f4460b1743a7df5f1bf0c728a496c57e4a..0a66f1dfad21cc9964738ce753b5ac8859d9a265&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AFTYu1HAQdkStwzgxyDbKOLyDwTHEezL5yeqoxeZ0fc&m=YHD2SfBbnT6AYDCLfiEzPPKkbhi1m9JR8pMLc3pp39vqM1wjkv2IWS_58TgRDgoG&s=iTCGYIs7havCZYSJP48o1ulNZijPfOXKqVr3F__M25I&e=> .
The following motion is proposed by Aaron Gable (Let's Encrypt / ISRG) and endorsed by Rich Smith (DigiCert) and Chris Clements (Google).
--- Motion Begins ---
Modify the "Baseline Requirements for the Issuance and Management of Publicly-Trusted Server Certificates", based on Version 2.2.7, per the following redline:
--- Motion Ends ---
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (at least 7 days):
* Start time: 2026-06-12 17:00 UTC
* End time: 2026-06-19 17:00 UTC or later
Vote for approval (7 days):
* Start time: 2026-06-23 23:20 UTC
* End time: 2026-06-30 23:20 UTC
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org <mailto:servercert-w...@groups.cabforum.org> .
To view this discussion visit https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_a_groups.cabforum.org_d_msgid_servercert-2Dwg_CAEmnErcv-252Bs4-2DYRDx8F31j1HMtrxnVQLQCZs3ifO2KxNvQVouTA-2540mail.gmail.com&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AFTYu1HAQdkStwzgxyDbKOLyDwTHEezL5yeqoxeZ0fc&m=YHD2SfBbnT6AYDCLfiEzPPKkbhi1m9JR8pMLc3pp39vqM1wjkv2IWS_58TgRDgoG&s=z6afHkQblLc97sJHihwe_gZPg2i27bTKUuUmORdeq2s&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_a_groups.cabforum.org_d_msgid_servercert-2Dwg_CAEmnErcv-252Bs4-2DYRDx8F31j1HMtrxnVQLQCZs3ifO2KxNvQVouTA-2540mail.gmail.com-3Futm-5Fmedium-3Demail-26utm-5Fsource-3Dfooter&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AFTYu1HAQdkStwzgxyDbKOLyDwTHEezL5yeqoxeZ0fc&m=YHD2SfBbnT6AYDCLfiEzPPKkbhi1m9JR8pMLc3pp39vqM1wjkv2IWS_58TgRDgoG&s=mKfIauMEtFddpqXy69lXuUdHW-PfDnC6MctHktBI7C8&e=> .
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_a_groups.cabforum.org_d_msgid_servercert-2Dwg_OS3P286MB3194BB29D5957F323A83E796CAED2-2540OS3P286MB3194.JPNP286.PROD.OUTLOOK.COM&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AFTYu1HAQdkStwzgxyDbKOLyDwTHEezL5yeqoxeZ0fc&m=YHD2SfBbnT6AYDCLfiEzPPKkbhi1m9JR8pMLc3pp39vqM1wjkv2IWS_58TgRDgoG&s=C50G5diu0QHrxsSi8kM-_dLC8kWjjoQY8yJlGNW8KL4&e=.
WISeKey SA
Pedro Fuentes
CSO - Trust Services Manager
Office: + 41 (0) 22 594 30 00
Mobile: + 41 (0) 791 274 790
CSO - Trust Services Manager
Office: + 41 (0) 22 594 30 00
Mobile: + 41 (0) 791 274 790
Address: Avenue
Louis-Casaï 58 | 1216 Cointrin | Switzerland
THIS IS A TRUSTED MAIL: This message is digitally signed with a WISeKey identity. If you get a mail from WISeKey please check the signature to avoid security risks
CONFIDENTIALITY: This email and any files transmitted with it can be confidential and it’s intended solely for the use of the individual or entity to which they are addressed.
If you are not the named addressee you should not disseminate, distribute or copy this e-mail. If you have received this email in error please notify the sender
DISCLAIMER: WISeKey does not warrant the accuracy or completeness of this message and does not accept any liability for any errors or omissions herein as this message has
been transmitted over a public network. Internet communications cannot be guaranteed to be secure or error-free as information may be intercepted, corrupted, or contain viruses. Attachments to this e-mail are checked for viruses; however, we do not accept any
liability for any damage sustained by viruses and therefore you are kindly requested to check for viruses upon receipt.
Entschew, Enrico
Jun 29, 2026, 10:39:48 AMJun 29
to server...@groups.cabforum.org, Rich Smith, Chris Clements
D-Trust votes „YES“ on Ballot SC-101v2.
Thanks,
Enrico
Von: 'Aaron Gable' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Gesendet: Mittwoch, 24. Juni 2026 01:19
An: server...@groups.cabforum.org
Cc: Rich Smith <rich....@digicert.com>; Chris Clements <ccle...@google.com>
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
servercert-w...@groups.cabforum.org.
Rebecca Kelley
Jun 29, 2026, 12:35:56 PM (14 days ago) Jun 29
to Server Certificate WG (CA/B Forum), e.ent...@d-trust.net, Rich Smith, ccle...@google.com
SSL.com votes "YES" on Ballot SC-101v2.
- Rebecca Kelley
郭宗閔
Jun 29, 2026, 11:05:26 PM (14 days ago) Jun 29
to server...@groups.cabforum.org
Chunghwa Telecom votes YES on Ballot SC-101v2.
Regards,
Tsung-Min Kuo
Chunghwa Telecom Co., Ltd., Taiwan (R.O.C.)
From: 'Aaron Gable' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Wednesday, June 24, 2026 7:19 AM
To: server...@groups.cabforum.org
Cc: Rich Smith <rich....@digicert.com>; Chris
Clements <ccle...@google.com>
Subject: [外部郵件][Servercert-wg] Voting Period Begins: Ballot SC-101v2: Clarify Authorization Domain Names
--
You received this message because you are subscribed to the Google
Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit
https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAEmnErcv%2Bs4-YRDx8F31j1HMtrxnVQLQCZs3ifO2KxNvQVouTA%40mail.gmail.com.
本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任.
Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited. Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.
qi_ji...@itrus.com.cn
Jun 29, 2026, 11:16:52 PM (14 days ago) Jun 29
to servercert-wg, Rich Smith, ccle...@google.com
--
Yoshihiko Matsuo
Jun 30, 2026, 1:01:06 AM (13 days ago) Jun 30
to server...@groups.cabforum.org
JPRS votes YES on Ballot SC-101v2.
Yoshihiko Matsuo(JPRS)
On Tue, 23 Jun 2026 16:19:01 -0700
"'Aaron Gable' via Server Certificate WG (CA/B Forum)" <server...@groups.cabforum.org> wrote:
> *Ballot SC-101v2: Clarify Authorization Domain Names*
>
> *Summary of the Ballot*
> version* of the Baseline Requirements until November 15, 2026. This is
> .
> - End time: 2026-06-19 17:00 UTC or later
> - End time: 2026-06-30 23:20 UTC
Yoshihiko Matsuo(JPRS)
On Tue, 23 Jun 2026 16:19:01 -0700
"'Aaron Gable' via Server Certificate WG (CA/B Forum)" <server...@groups.cabforum.org> wrote:
> *Ballot SC-101v2: Clarify Authorization Domain Names*
>
> *Summary of the Ballot*
>
> In Section 3.2.2.4, explicitly describe the algorithm by which a CA may
> derive an Authorization Domain Name from an applied-for FQDN. The algorithm
> described is consistent with the most common interpretation of the current
> definition of ADN, so this is not expected to be a disruptive change for
> most CAs, but it removes ambiguity and closes one security issue (described
> below).
>
> Simplify the definition of Authorization Domain Name to be merely
> descriptive. Update all validation methods to describe how they validate
> control of the selected ADN. Collapse all previous statements about
> validation method suitability for wildcard and ending-in-the-same-suffix
> validation into a table in Section 3.2.2.4. As a knock-on effect, simplify
> the definitions of Base Domain Name and Domain Contact.
>
> Although these changes are simple, they are also sweeping. As such, the
> ballot includes a provision that CAs may comply with Section 3.2.2.4
> of the *previous
> In Section 3.2.2.4, explicitly describe the algorithm by which a CA may
> derive an Authorization Domain Name from an applied-for FQDN. The algorithm
> described is consistent with the most common interpretation of the current
> definition of ADN, so this is not expected to be a disruptive change for
> most CAs, but it removes ambiguity and closes one security issue (described
> below).
>
> Simplify the definition of Authorization Domain Name to be merely
> descriptive. Update all validation methods to describe how they validate
> control of the selected ADN. Collapse all previous statements about
> validation method suitability for wildcard and ending-in-the-same-suffix
> validation into a table in Section 3.2.2.4. As a knock-on effect, simplify
> the definitions of Base Domain Name and Domain Contact.
>
> Although these changes are simple, they are also sweeping. As such, the
> ballot includes a provision that CAs may comply with Section 3.2.2.4
> version* of the Baseline Requirements until November 15, 2026. This is
> derived from the approach taken by v2.0 of the Network Security
> Requirements.
>
> *Background of the Ballot*
> Requirements.
>
>
> The existing definition of Authorization Domain Name has two severe issues:
> a) It contains normative policy language (describing how to derive an ADN)
> but attempts to be a concise and descriptive definition, leading to
> ambiguity as to whether parts of the definition can be performed
> exclusively, in sequence, repeatedly, or otherwise.
> b) Under some interpretations, it allows for issuance of certificates for
> names over which the applicant has not demonstrated any control.
>
> Specifically, one interpretation of the current definition of an ADN is
> that a CA may prune labels from the left-hand side of the FQDN, then follow
> one or more CNAMEs, and then use the resulting FQDN as the ADN. However,
> just because `example.com` has a CNAME pointing to `example.org`, that does
> not give the operators of `example.org` any control over *subdomains* of
> The existing definition of Authorization Domain Name has two severe issues:
> a) It contains normative policy language (describing how to derive an ADN)
> but attempts to be a concise and descriptive definition, leading to
> ambiguity as to whether parts of the definition can be performed
> exclusively, in sequence, repeatedly, or otherwise.
> b) Under some interpretations, it allows for issuance of certificates for
> names over which the applicant has not demonstrated any control.
>
> Specifically, one interpretation of the current definition of an ADN is
> that a CA may prune labels from the left-hand side of the FQDN, then follow
> one or more CNAMEs, and then use the resulting FQDN as the ADN. However,
> just because `example.com` has a CNAME pointing to `example.org`, that does
> such as `blog.example.com`. Under this interpretation, an entity capable of
> demonstrating control of a CNAME (such as a CDN operator) might be able to
> get issuance of certificates for arbitrary subdomains of names that are
> CNAMEd to them. This is not good.
>
> This ballot resolves the issue by much more strictly describing the
> acceptable ADN derivation algorithm. In particular:
> - The ADN must be selected *after* the validation method has been selected.
> demonstrating control of a CNAME (such as a CDN operator) might be able to
> get issuance of certificates for arbitrary subdomains of names that are
> CNAMEd to them. This is not good.
>
> This ballot resolves the issue by much more strictly describing the
> acceptable ADN derivation algorithm. In particular:
> - Only certain methods (those which perform validation at the name itself,
> not at a underscore-prefixed subdomain of it) can use the "cname" step of
> the ADN algorithm.
> - Only certain methods (those which currently allow issuance for "other
> FQDNs that end with all the Domain Labels of the validated FQDN") can use
> the "prune" step of the ADN algorithm.
> - Following CNAMEs must happen before pruning labels, if both operations
> are performed.
>
> This makes it much easier for CAs to implement provably-compliant ADN
> derivation algorithms, and closes the security hole described above.
>
> This ballot also explicitly acknowledges something that has always been
> true: that all validation methods are in fact validating control over the
> ADN, not the applied-for FQDN (unless the CA has selected the ADN to be
> exactly equal to the applied-for FQDN). This means that validation data
> reuse also works at the ADN level: if two applied-for FQDNs can both be
> turned into the same ADN, then demonstrating control of that ADN is valid
> for the issuance of both applied-for FQDNs.
>
> This ballot differs from the original SC-101 in only one substantive way:
> it adds an effective date for the change to Section 3.2.2.5.3, which is not
> covered by the general effective date covering all of Section 3.2.2.4. The
> other changes are merely editorial. You can see a diff from SC-101 to
> SC-101v2 here
> <https://github.com/cabforum/servercert/pull/627/changes/709bb8f4460b1743a7df5f1bf0c728a496c57e4a..0a66f1dfad21cc9964738ce753b5ac8859d9a265>
> not at a underscore-prefixed subdomain of it) can use the "cname" step of
> the ADN algorithm.
> - Only certain methods (those which currently allow issuance for "other
> FQDNs that end with all the Domain Labels of the validated FQDN") can use
> the "prune" step of the ADN algorithm.
> - Following CNAMEs must happen before pruning labels, if both operations
> are performed.
>
> This makes it much easier for CAs to implement provably-compliant ADN
> derivation algorithms, and closes the security hole described above.
>
> This ballot also explicitly acknowledges something that has always been
> true: that all validation methods are in fact validating control over the
> ADN, not the applied-for FQDN (unless the CA has selected the ADN to be
> exactly equal to the applied-for FQDN). This means that validation data
> reuse also works at the ADN level: if two applied-for FQDNs can both be
> turned into the same ADN, then demonstrating control of that ADN is valid
> for the issuance of both applied-for FQDNs.
>
> This ballot differs from the original SC-101 in only one substantive way:
> it adds an effective date for the change to Section 3.2.2.5.3, which is not
> covered by the general effective date covering all of Section 3.2.2.4. The
> other changes are merely editorial. You can see a diff from SC-101 to
> SC-101v2 here
> .
>
> The following motion is proposed by Aaron Gable (Let's Encrypt / ISRG) and
> endorsed by Rich Smith (DigiCert) and Chris Clements (Google).
>
> *--- Motion Begins ---*
> The following motion is proposed by Aaron Gable (Let's Encrypt / ISRG) and
> endorsed by Rich Smith (DigiCert) and Chris Clements (Google).
>
>
> Modify the "Baseline Requirements for the Issuance and Management of
> Publicly-Trusted Server Certificates", based on Version 2.2.7, per the
> following redline:
>
> https://github.com/cabforum/servercert/compare/1bcb34993331313c92ac7d6af778e81ca3d5faff...0a66f1dfad21cc9964738ce753b5ac8859d9a265
>
> *--- Motion Ends ---*
> Modify the "Baseline Requirements for the Issuance and Management of
> Publicly-Trusted Server Certificates", based on Version 2.2.7, per the
> following redline:
>
> https://github.com/cabforum/servercert/compare/1bcb34993331313c92ac7d6af778e81ca3d5faff...0a66f1dfad21cc9964738ce753b5ac8859d9a265
>
>
> This ballot proposes a Final Maintenance Guideline. The procedure for
> approval of this ballot is as follows:
>
> Discussion (at least 7 days):
>
> - Start time: 2026-06-12 17:00 UTC
> This ballot proposes a Final Maintenance Guideline. The procedure for
> approval of this ballot is as follows:
>
> Discussion (at least 7 days):
>
> - End time: 2026-06-19 17:00 UTC or later
>
> Vote for approval (7 days):
>
> - Start time: 2026-06-23 23:20 UTC
> Vote for approval (7 days):
>
> - End time: 2026-06-30 23:20 UTC
Kateryna Aleksieieva
Jun 30, 2026, 3:23:40 AM (13 days ago) Jun 30
to server...@groups.cabforum.org
Certum votes YES on SC-101v2
Pozdrawiam
Kateryna Aleksieieva
From: 'Aaron Gable' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Wednesday, June 24, 2026 1:19 AM
To: server...@groups.cabforum.org
Cc: Rich Smith <rich....@digicert.com>; Chris Clements <ccle...@google.com>
--
Backman, Antti
Jun 30, 2026, 3:35:25 AM (13 days ago) Jun 30
to server...@groups.cabforum.org, Rich Smith, Chris Clements
Telia votes ‘Yes’ on Ballot SC-101v2
//Antti
From: 'Aaron Gable' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Wednesday, 24. June 2026 at 2.19
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Cc: Rich Smith <rich....@digicert.com>; Chris Clements <ccle...@google.com>
Subject: [Servercert-wg] Voting Period Begins: Ballot SC-101v2: Clarify Authorization Domain Names
Caution: This is an external email. Stop, assess and verify. Please take care when clicking links or opening attachments! When in doubt, report it using “report phishing” function. |
Inigo Barreira
Jun 30, 2026, 4:01:59 AM (13 days ago) Jun 30
to server...@groups.cabforum.org, Rich Smith, Chris Clements
Sectigo votes yes
De: 'Aaron Gable' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Enviado el: miércoles, 24 de junio de 2026 1:19
Para: server...@groups.cabforum.org
CC: Rich Smith <rich....@digicert.com>; Chris Clements <ccle...@google.com>
Asunto: [Servercert-wg] Voting Period Begins: Ballot SC-101v2: Clarify Authorization Domain Names
Ballot SC-101v2: Clarify Authorization Domain Names Summary of the Ballot In Section 3. 2. 2. 4, explicitly describe the algorithm by which a CA may derive an Authorization Domain Name from an applied-for FQDN. The algorithm described is consistent
ZjQcmQRYFpfptBannerStart
|
ZjQcmQRYFpfptBannerEnd
Peter Miškovič
Jun 30, 2026, 7:26:45 AM (13 days ago) Jun 30
to server...@groups.cabforum.org
Disig votes „YES“ on Ballot SC-101v2: Clarify Authorization Domain Names.
Regards,
Peter Miskovic
From: 'Aaron Gable' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: streda 24. júna 2026 1:19
To: server...@groups.cabforum.org
Cc: Rich Smith <rich....@digicert.com>; Chris Clements <ccle...@google.com>
Subject: [Servercert-wg] Voting Period Begins: Ballot SC-101v2: Clarify Authorization Domain Names
Ballot SC-101v2: Clarify Authorization Domain Names
Summary of the Ballot
In Section 3.2.2.4, explicitly describe the algorithm by which a CA may derive an Authorization Domain Name from an applied-for FQDN. The algorithm described is consistent with the most common interpretation of the current definition of ADN, so this is not expected to be a disruptive change for most CAs, but it removes ambiguity and closes one security issue (described below).
Christophe Bonjean
Jun 30, 2026, 7:42:49 AM (13 days ago) Jun 30
to server...@groups.cabforum.org
GlobalSign votes “Yes” on Ballot SC-101v2.
Christophe
Karina Sirota Goodley
Jun 30, 2026, 1:00:24 PM (13 days ago) Jun 30
to server...@groups.cabforum.org
Microsoft votes Yes on SC-101v2.
Best, Karina
From: 'Aaron Gable' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Tuesday, June 23, 2026 6:19 PM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Alvin Wang
Jun 30, 2026, 10:06:41 PM (13 days ago) Jun 30
to Server Certificate WG (CA/B Forum), aa...@letsencrypt.org, Rich Smith, ccle...@google.com
SHECA votes “Yes” on Ballot SC-101v2 .
Alvin.Wang
On Wednesday, June 24, 2026 at 7:19:17 AM UTC+8 aa...@letsencrypt.org wrote:
Dimitris Zacharopoulos (HARICA)
Jul 2, 2026, 2:10:48 AM (11 days ago) Jul 2
to server...@groups.cabforum.org
This vote was received after the end of the voting period so it
cannot be counted.
Thank you,
Dimitris.
Thank you,
Dimitris.
-- Dimitris Zacharopoulos CA/B Forum SCWG Chair
Reply all
Reply to author
Forward
0 new messages