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.

[Tim Hollebeek]

This seems like a good time to remind people that the requirements for the WebPKI are the Baseline Requirements. IETF does not have any jurisdiction over the WebPKI.

Compliance with IETF drafts, even after they have been published as RFCs, is voluntary. CAs are not required to comply with IETF RFCs unless they are normatively referenced by the Baseline Requirements, a root program policy, or other normative standard.

IETF drafts, like draft-ietf-acme-dns-persist, are simply documents that are being worked on by an IETF WG, and therefore do not even have the approval of IETF itself (yet).

Attempting to comply with in-progress drafts comes with a lot of risk, as you're trying to track a moving target which isn't even approved by IETF yet. And yes you need to comply with the Baseline Requirements at all times. Just because text is inserted into an ACME working group draft doesn't mean the BRs allow it.

-Tim

---

From: '黃晟(orca)' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Thursday, May 14, 2026 4:11 AM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: RE: [Servercert-wg] Initial Vote Results on Ballot SC098: Process RFC 8657 CAA Parameters

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/28ab33893fd84969a1bad4a421dcc697%40twca.com.tw.

[蔡家宏(chtsai)]

We fully recognize that the BR are the ultimate authority; however, we are also closely monitoring the development of other specifications within the ecosystem.

 

We have conducted a comparison between SC-098 and draft-ietf-acme-dns-persist. We would like to confirm whether the text of SC-098 only covers modes 3a and 3b as described in PR#58.

Specifically, is mode 3c excluded from the current scope permitted by SC-098? Or is our understanding incorrect, and all three modes—3a, 3b, and 3c—actually fall within the permitted range of SC-098?

 

Although the vote has already taken place, we are raising this question to ensure our development is precise and fully compliant with the BR.

If it is inappropriate to compare these two, please feel free to clarify and correct our misunderstanding.

 

Thank you.

 

 

Best Regards

 

蔡家宏 Chya-Hung Tsai

Director

Identification & Certificate Research
Tel: +886-2-2370-8886 ext. 722
Fax: +886-2-2388-6720
Email: cht...@twca.com.tw

10F., No. 85, Yanping South Road,

Taipei 100002, Taiwan(R.O.C.)
https://www.twca.com.tw

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/SN7PR14MB6492551835CBB2C446BA308D83072%40SN7PR14MB6492.namprd14.prod.outlook.com.

[Henry Birge-Lee]

Hi Chya-Hung Tsai,

I wanted to clarify a couple things. Tim's statements are absolutely correct that IETF drafts should not impact how BR language is interpreted. That said, as an author of the IETF draft (and given that Michael Slaughter is the author of SC-088v3 and the EITF draft), we do very much intend to align the two in the long run and I think foreshadowing this conversation and reducing the information divide between these communities is valuable.

Some key clarifications I wanted to make:

1) SC-098/RFC 8657 should be considered a separate document, standard, and definition of account when compared to dns-persist (the IETF draft) or SC-088v3. There is an RFC 8657 reference in SC-088v3 but this is more for the syntax of what an account uri looks like (the reference reads "where the parameter value is a unique URI (as described by RFC 8657, Section 3) identifying the account of the Applicant which requested validation for this FQDN"). The account restriction used in SC-088v3 of  "identifying the account of the Applicant which requested validation for this FQDN" does not rely on an RFC 8657 reference. Thus, there may exist definitions of account URIs that satisfy SC-088v3 but not RFC 8657.

2) Mode 3c of the recent pull request operates on the principle of a non-ACME account. The justification is such:

1. An applicant has an account with a CA that is not based on the ACME protocol and such account has a URI (not an ACME account URI, just an identifier used by the CA for the non-ACME account) which properly "identifying the account of the Applicant" and only that one non-ACME account.

2. This applicant and non-ACME account could cleanly walk through SC-088v3 persistent DNS validation using a non-ACME mode of interacting and signing certificates.

3. For the purposes of deployment of certificates on operational systems, said applicant has authorized several ACME public keys to act on the applicant's behalf. The these can best be thought of similar to API keys that authenticate infrastructure which belongs to that applicant to request certificates under the applicant's account. The ACME "accounts" in this scenario are not unique applicants, instead just credentials used for authenticating to the CA within the applicant's main account.

4. Under these circumstances, the CA has authenticated the applicant which has completed domain control validation using a non-ACME method. In theory the ACME DCV check could even be bypassed using an existing cached validation from the applicant. However, for the purpose of flexibility in the IETF protocol, we wanted to give the CA the ability to perform a check of this non-ACME overarching account URI during the ACME protocol DCV step even though the actual check being done by the CA is best thought of as a non-ACME DCV check permitted under SC-088v3.

I understand this interpretation may not be homogeneous and it may be deemed beneficial to modify the baseline requirements to address this method directly. However, I did want to outline a justification for the use of method 3c for SC-088v3 validation under the current BRs.

3) As I stated above, I consider the use of such accounts for RFC 8657 CAA parameters a different topic. There is also some language in RFC 8657 that could be interpreted to permit such accounts:

"The value of this parameter, if specified, MUST be a URI [RFC3986] identifying a specific CA account." <- implies the account does not need to be an ACME account.

""CA account" means an object that is maintained by a specific CA, that may reques tthe issuance of certificates, and that represents a specific entity or group of related entities." <- acknowledges there may be numeries identity objects associated with an account.

However, I would personally exercise additional caution in this space (i.e., more caution regarding use for RFC 8657 than SC-088v3 validation).

4) There is talk from Mike Ownsworth (chair of the ACME WG) that the privacy discussions from dns-persist, may merit an update to RFC 8657. This is not a draft or even plan yet, but I did want to put it out there that there could be a larger effort to align all of these standards in the long run.

5) As Tim mentioned the IETF draft is not finalized so there could still be adjustments to this language.

I would conclude that I personally find mode 3c justifiable for SC-088v3 validation as written since it pins back to a non-ACME account that is identified 1:1 via an account URI. I would probably not extend this to RFC 8657 parameters, but there is some potentially justifying language.

Best,

Henry

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/df60558602ff424487821e0de0af6de5%40twca.com.tw.

[蔡家宏(chtsai)]

Hi Henry,

 

Thank you very much for your clear explanation. We truly appreciate your great work in leading and driving these standards. We look forward to seeing them eventually align across the ecosystem.

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAGxVKU5GhSPHvaxLTmnxP2EupaFgpyVY7FM44cHsifj6Szf7WQ%40mail.gmail.com.

[Tim Hollebeek]

Yes, thanks for everyone working on this. Someone did ask me recently to weigh in on whether the BR language saying 'account' was referring to the same thing as the ACME drafts do when they talk about 'account' and I agree that those are two different things. The BRs are referring to a CA's isolation between different customer accounts, which may not map cleanly or at all onto ACME accounts.

The easiest way to see this is because the customers may not be using ACME at all, so the interpretation that they are the same cannot be correct, as the BR language is intended to apply more broadly to non-ACME use cases as well.

We should probably clean up the unintended terminology confusion. Once that confusion is cleared up, there isn't any conflict between the current draft and the current BRs, as far as I can see.

-Tim

---

From: '蔡家宏(chtsai)' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Sunday, May 17, 2026 8:13 PM

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/fc334c1caff94c8b9ab13fe0ca072c33%40twca.com.tw.

[Aaron Gable]

Hi all,

We'd like to ask how other CAs and root programs interpret one clause from this ballot in light of the ongoing standardization of ACME dns-persist:

> If the CA supports domain validation methods that are not registered in the IANA ACME Validation Methods registry, the CA MUST interpret and process `validationmethods` labels formed by concatenating the string ‘ca-tbr-’ with the BR 3.2.2.4 subsection number

Specifically, Section 3.2.2.4.22 defines the "DNS TXT Record with Persistent Value" validation method. This method is expected to be standardized as "dns-persist-01" via this IETF ACME draft. But crucially, it has not yet been standardized, and therefore the label "dns-persist-01" is not yet registered in the IANA ACME Validation Methods registry.

If a CA implements dns-persist-01 today, it seems clear that they are actually implementing BRs 3.2.2.4.22, and therefore MUST support "ca-tbr-22" in CAA records. That's fine.

The question is this: must they, by virtue of supporting a single non-ACME method, then support the "ca-tbr-X" format for all of their validation methods? The quoted clause from the ballot text does not say "the CA MUST interpret and process `validationmethods` labels for that validation method...", it just says that they must interpret and process such labels, with no comment for the scope. Is the intent that they uniformly support "ca-tbr-X" labels across all validation methods? Or is the intent only that they must do so for individual validation methods which are not in the ACME registry?

Thank you,

Aaron

[Henry Birge-Lee]

Hi all,

Just to add to Aaron's point, there could also be an interesting interaction with the mode 3c with non-ACME acocunturis discussed above. Let's assume dns-persist does make it to the ACME registry but an applicant uses mode 3c. Part of the justification for allowing that is that it's not the ACME account being validated but the CA's non-ACME subscriber account. This could lead to an interesting question of whether "dns-persist-01" is appropriate to describe mode 3c of operation (even after it is in the ACME registry) or if it has to be "ca-tbr-22". Worth thinking about to avoid confusion down the road.

Best,

Henry

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAEmnErdAXAD%3DY0KUGP3CWxLmvN2we7r1ewiYVv2JRt51xv%2B5iQ%40mail.gmail.com.

[Gurleen Grewal]

Hi Aaron,

As the person who suggested the specific wording for this clause, I can clarify the intent behind it.

My intent was not to require CAs to uniformly support the ca-tbr-X labels across all validation methods simply because they support one non-registered method. Rather, the requirement was designed to apply only to individual validation methods that are not currently registered in the IANA ACME Validation Methods registry.

The purpose of this requirement is to ensure a predictable and standardized fallback for any method defined in the BRs that does not yet have a corresponding ACME identifier. It is not intended to create redundant overhead for validation methods that already have established, registered identifiers.

I hope this helps clarify the intended scope.

Best,
Gurleen

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAEmnErdAXAD%3DY0KUGP3CWxLmvN2we7r1ewiYVv2JRt51xv%2B5iQ%40mail.gmail.com.

[Wayne Thayer]

I agree with Gurleen and I think this sentence makes that intent sufficiently clear:

If a CA performs domain validation using a mechanism that can be represented by multiple labels (e.g. 'http-01' and 'ca-tbr-19'), the CA SHOULD accept any of the labels as granting permission to issue.

Having said that, I'm not opposed to a clarification, especially if there is consensus for doing so in the next cleanup ballot.

Thanks,

Wayne

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAHidiLH5KcJpmBowp4BkZG0pysyVjBH6aGp6Fyi8K%2BNZ2wF2hA%40mail.gmail.com.