Initial Vote Results on Ballot SC098: Process RFC 8657 CAA Parameters
Dimitris Zacharopoulos (HARICA)
The voting period for SC098: Process RFC 8657 CAA Parameters has completed. The ballot has: PASSED
Voting Results
Certificate Issuers
23 votes in total:
* 22 voting YES: Actalis S.p.A., Amazon, Asseco Data Systems SA
(Certum), Chunghwa Telecom, Cybertrust Japan, eMudhra, Fastly,
GlobalSign, GoDaddy, IdenTrust, iTrusChina, Japan Registry
Services, NAVER Cloud Trust Services, OISTE Foundation, SECOM
Trust Systems, Sectigo, SSL.com, SwissSign, Telia Company,
TrustAsia, TWCA, Visa
* 1 voting NO: HARICA
* 0 ABSTAIN:
Certificate Consumers
3 votes in total:
* 3 voting YES: Apple, Google, Mozilla
* 0 voting NO:
* 0 ABSTAIN:
Bylaws Requirements
1. Bylaw 2.3(6) requires:
* In order for a ballot to be adopted by the Forum, two‐thirds
(2/3) or more of the votes cast by the Voting Members in the
Certificate Issuer category must be in favor of the ballot. This
requirement was MET.
* at least fifty percent (50%) plus one (1) of the votes cast by
the Voting Members in the Certificate Consumer category must be in
favor of the ballot. This requirement was MET.
* At least one (1) Voting Member in each category must vote in
favor of a ballot for the ballot to be adopted. This requirement
was MET.
2. Bylaw 2.3(7) requires:
* A ballot result will be considered valid only when more than
half of the number of currently active Voting Members has
participated. The number of currently active Voting Members is the
average number of Voting Member organizations that have
participated in the previous three (3) Forum Meetings and Forum
Teleconferences.
* the quorum was 15 for this ballot. This requirement
was MET.
This ballot now enters the IP Rights Review Period to permit
members to review the ballot for relevant IP rights issues. This
will be notified in a separate email.
黃晟(orca)
Hi all,
Now that SC-098 has passed and CAA-side accounturi rules are in the BR, we at TWCA went back to look at BR §3.2.2.4.22 (introduced by SC-088v3).
Both methods utilize the same RFC 8657 accounturi concept, but we noticed a development on the IETF side yesterday that seems to diverge from the current BR text.
Specifically, draft-ietf-acme-dns-persist PR #58 (addressing Issue #57) was merged into the WG main branch on 2026-05-13. This update restructures §4.1 item 3 into three explicit modes:
- (3a) ACME account URL
- (3b) Alternative URI (each URI uniquely and permanently identifies a single ACME account)
- (3c) Subscriber-account URI (1:N, where one URI represents a newly-defined "Subscriber Account" encompassing multiple ACME accounts)
BR §3.2.2.4.22 item (3) currently reads:
"The issue-value MUST contain an accounturi parameter, where the parameter value is a unique URI... identifying the account of the Applicant which requested validation for this FQDN."
We are reading the current BR language as binding at the per-account level — "identifying the account... which requested validation" is singular — so modes 3a and 3b fit, but 3c doesn't.
Our interpretation is that mode 3c remains unpermitted under the current Baseline Requirements until the Forum takes action to align the BR with the updated draft. We plan to implement on that conservative basis.
We are flagging this in case our reading is off, or in case other CAs preparing implementation are hitting the same question. We are not requesting any change to the BR text at this time.
Thank you.
Best regards,
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/94d6b8ac-365b-43dc-b98b-cf06163bf4d6%40harica.gr.