Discussion Begins: Ballot SC-098: Process RFC 8657 CAA Parameters

[Wayne Thayer]

Ballot SC-098: Process RFC 8657 CAA Parameters 

Summary of the Ballot

This ballot adds the requirement that CAs process the Certification Authority Authorization (CAA) parameters defined in RFC 8657. These parameters allow the issuance policy specified by a CAA record to include the account and domain validation methods that may be used to issue a certificate for the subject domain.

The ballot defines a syntax for specifying non-ACME domain validation methods in section 4.2.2.1.3.

CAs supporting non-ACME accounts must document the accepted accounturi format in their CP or CPS.

These requirements take effect on March 15, 2027.

The ballot also moves and consolidates CAA requirements into section 4.2.1.

Summary of Discussion

• This ballot has undergone extensive discussion in the Validation Working Group dating back to 2024, and in https://github.com/cabforum/servercert/pull/567.

• The value of the CAA extensions defined in RFC 8657 will only be realized if CAs process the parameters rather than ignoring them.

• We originally considered including DNSSEC requirements in this ballot but decided to separate them into ballot SC-085.

• Consensus formed that Non-ACME validation methods must use a specific syntax to avoid conflicts and provide consistency across CAs.

Special thanks to Grace Cimaszewski for helping to move this ballot forward.

---

 The following motion has been proposed by Wayne Thayer (Fastly) and endorsed by Chris Clements (Google) and Ben Wilson (Mozilla).

 

--- Motion Begins ---

This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.2.6 

Redline: https://github.com/cabforum/servercert/compare/168e0aa8cafe753c85a94b5a8f28541beda48201..bbc51ec3b7b8df9a61ffee5c881b16e0db9a91f3

--- 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-04-02 15:00 UTC

• End time: no earlier than 2026-04-09 15:00 UTC

Vote for approval (7 days)

• Start time: TBD

• End time: TBD

[Dimitris Zacharopoulos (HARICA)]

As Aaron correct highlighted in this thread, there is some subtlety in the BRs around the mapping between "ca-tbr-7" and "dns-01". I don't think an implementer just reading the BRs can easily come to that conclusion.

Right now, we have the following one-to-one mappings between the BRs and the RFC:

• ca-tbr-19 and http-01
• ca-tbr-20 and tls-alpn-01

As mentioned, ca-tbr-7 is a superset of dns-01.

It might make sense to first introduce a new domain validation method for DNS-ACME, just like we do for the agreed-upon change to website - ACME (3.2.2.4.19).


Thanks,
Dimitris.

--
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/CAPh8bk-n6kpuRqL3yKK64SQb6w0sBR79WuaLLnd6qNGp5GdU7Q%40mail.gmail.com.

[Wayne Thayer]

During the SCWG call last week we discussed this ballot and concluded:

- We will not delay this ballot until a new validation method specific to ACME dns-01 is considered. That will become a separate workstream in the Validation subcommittee.

- We agreed to change the example in section 4.2.2.1.3  to two methods that are equivalent. I have updated the text as follows: 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.

Before starting discussion on v2 of this ballot, I have one additional question: should we require CAs to accept validationmethods values in upper or lower case, e.g. 'ca-tbe-7' and 'CA-TBR-7', 'dns-01' and 'DNS-01'?

Thanks,

Wayne

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/1aa10ad2-3b01-40ef-9d07-735f08a9e11b%40harica.gr.

[Backman, Antti]

Hi, 

I got wonder that why we have selected the “ca-tbr-“ as the prefix. There’s other use cases that we’re obligated to record the full section identifier for the method, like in issuance logs when we’re logging validation information.

Couldn’t we just use the same identifier here for consistency. Is there some restrictions that I am not aware of, in doing so. 

So instead of ca-tbr-7 we would just expect 3.2.2.4.7 to be set in the CAA records? 

Not that the proposed would be a problem, but I feel it would be better to be consistent through the BRs how we use the DCV method identification through the different use cases. 

//Antti

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

[Corey Bonnell]

• Before starting discussion on v2 of this ballot, I have one additional question: should we require CAs to accept validationmethods values in upper or lower case, e.g. 'ca-tbe-7' and 'CA-TBR-7', 'dns-01' and 'DNS-01'?

 

I went through RFC 8657 and didn’t see any allowance for case-insensitive matching. Since RFC 8657 is silent on this, the required behavior is an exact case-sensitive match. There’s no benefit in allowing case-insensitivity, so I think CAs must perform an exact match and reject labels such as “DNS-01” or “Ca-TbR-7”.

 

Thanks,

Corey

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

[Martijn Katerbarg]

Wayne, there’s two items of feedback I’d like to address. 

One is a minor one: In the current redline, there’s a number of now-historic Effective Dates. I’d suggest we remove those, saving us a cleanup later on.

The other item relates to the way RFC 8657 is scoped, and I wonder if there’s appetite to allow for an exception to the RFC (and long term, get the RFC updated). 

CAA Parameters, specifically the accounturi for non-ACME requests, seems like a simple task. Most subscribers will have 1, or only a hand full of non-ACME accounts with one or a few CAs, thus adding a few different CAA records, each allowing a separate account, seems do-able. 

With ACME however, this seems to be a bit differently.  From internal review, we can see that a large number of subscribers have only a single (per-subscriber) CA account, yet those individual subscribers have a massive amount of ACME accounts. In our setup, 1 CA account can be utilized by an unrestricted number of ACME accounts, this way, the subscriber has management available within a single account, but can utilize different ACME credentials for each individual server. 

While we only looked at the subscriber level and not the per-domain level, we expect there to be a likewise large overlap there. And this brings us to the issue:

If one of these subscribers does want to utilize the accounturi CAA parameter, they would need to add an incredible amount of CAA records. In several cases, we see the number of ACME accounts to be above the 100.000 count, all for 1 subscriber. 

Adding all these records is 1 problem. For a CA to verify those records, that’s another problem. Specifically on DNS, and I’ll be honest, we have not tested this, but I worry about how a nameserver would respond if it needs to send 100K+ CAA records for a single query, let along how that traffic would be transported and subsequintly processed by the CA, within the ACME-client’s timeout window.

As such I wonder if a BR exception to the RFC would make sense here, in which a CA would be allowed for a non-ACME account identifier (such as the "acct:” scheme) to be recognized as permission to issue even for ACME orders, if the ACME account in question does belong to the CA-account referenced within the CAA record.

I realize that adding a carveout here would only be half the task, as the Chrome Root Store Policy has language already in as well, which we hope to be able to address. However I believe it’s best we have this discussion in public first.

Regards,

Martijn

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

[Henry Birge-Lee]

Hi all,

I just wanted to chime in that I think this is a good topic. I am in favor of this approach. I think having ACME accounts as a certificate requesting automation layer that exists below a CA subscriber account is a valid and encouraged use case. Here the relevant subscriber identity that should be the reference in CAA records is the CA account not the ACME accounts (which may even be used like delegated credentials for individual servers). Also, this is highly synergistic with CAA tree climbing as many enterprises that do use CAA have it sit at their base domain and it is inherited by subdominas. If we assume this CA subscriber account and sub ACME account model, it mapps nicely to this type of CAA inheritance where individual ACME accounts might operate particular subdomains but they are all within the enterprises primary CA account which is specified in the CAA record.

It's also important to remember that this is a certificate limiting technology (in the absence of such a record or extension, the behavior would be permitted). As such having strict guidelines (e.g., not permitting CA account identifiers on ACME requests) is more likely to get people not to use the record which is detrimental from a security standpoint.

I will mention that we did a similar move away from strictly requiring ACME account IDs in URIs in the dns-persist Internet Draft (see section 4.1 https://ietf-wg-acme.github.io/draft-ietf-acme-dns-persist/draft-ietf-acme-dns-persist.html#name-validation-record-format ) although the motivation was different. The point there was to let CAs implement systems that minimize the infrastructure linking risk associated the reuse of ACME account ids by multiple domains that share a single hosting server. If an adversary can infer which domains are on the same server based on ACME account ids seen in dns-persist records (or CAA extensions), the adversary can exploit vulnerabilities at a less secure domain (say react2shell) and use that to compromise the hosting infrastructure of the more secure domain.

My overall thoughts are:

1) language in this ballot should permit the use of a non-ACME CA account identifier even when the actual certificate request is coming through on ACME

2) I would like for dns-persist and the CAA extensions to have the same requirements about account uris. This would mean that we would pull the permission to use a non-ACME account id into the I-D for dns-persist and (down the road) CAA extensions may also permit a many-to-one account uri obfuscation schemes using similar language to the dns-persist draft.

Best,

Henry

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

[Wayne Thayer]

Thanks everyone for the feedback.

Responding to Antti's suggestions on non-ACME validationmethods labels:

- The format of the label was debated when this ballot was first introduced. My recollection is that we chose the 'tls-br-' prefix to ensure that the label is not confused with other standards such as the S/MIME BRs. In practice, the EVGLs, S/MIME BRs, and Code Signing BRs do not currently appear to have any practical conflicts with the proposal to use '3.2.2.4.n' as the label. I'm not opposed to this change, but I'd like to hear from others if there is a preference for it over the current approach.

Responding to my question about case sensitivity:

- We discussed this on today's Validation subcommittee call and concluded that case insensitive matching should be optional. The proposed language is: The canonical representation of validationmethods labels is lowercase letters. However, the CA MAY perform case insensitive matching of labels. If the CA does perform case insensitive matching of labels, this practice MUST be documented in their CP and/or CPS.[1]

Responding to Martijn's request that we clean up effective dates in the sections that are modified by this ballot:

- I've made this change [2]

Responding to Martijn's suggestion that we allow CAs to accept their own account identifiers for ACME requests:

- We also discussed this on today's Validation subcommittee call and there was consensus that this is a good idea for the reason Martijn described. I drafted some language as a starting point for this change: For certificate requests made using the ACME protocol, the CA MAY also define an 'accounturi' format following the requirements in the prior bullet. If the CA accepts a self-defined 'accounturi' format for ACME requests, the CA MUST maintain a mapping between the self-defined label and the ACME accounts for which the self-defined label authorizes issuance. Note: this provision overrides RFC 8657 and is intended to allow Subscribers to link many ACME accounts to a single CA account. [3]

Thanks,

Wayne

[1] https://github.com/cabforum/servercert/commit/b225a243db8638bb11944fb7719094f87076ef29

[2] https://github.com/cabforum/servercert/commit/b237e8085d8fe17e959b05c4e71d6bde5f970091

[3] https://github.com/cabforum/servercert/commit/9dfa618672890065cc3fb7cc1eade587f6f32828

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

[Corey Bonnell]

Hi Wayne,

 

> - The format of the label was debated when this ballot was first introduced. My recollection is that we chose the 'tls-br-' prefix to ensure that the label is not confused with other standards such as the S/MIME BRs. In practice, the EVGLs, S/MIME BRs, and Code Signing BRs do not currently appear to have any practical conflicts with the proposal to use '3.2.2.4.n' as the label. I'm not opposed to this change, but I'd like to hear from others if there is a preference for it over the current approach.

 

RFC 8657 only allows letters, digits, and the hyphen character in validationmethods labels. Also, non-ACME validationmethod labels must be prefixed with “ca-“.

 

I think the way the ballot currently defines the labels is a good approach.

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