Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding
Extracted elements (20)
The "accounturi" specification provides a general mechanism for identifying certificate-requesting entities via URIs, not limited to ACME. CAs not implementing ACME MAY assign and recognize their own URIs arbitrarily, allowing future RFCs to specify use of other URI kinds.
This specification defines no new IANA registries. The "accounturi" and "validationmethods" parameter names live in a CA-defined namespace per RFC 8659, and CAs may freely adopt or ignore these semantics. ACME validation method labels reference the "ACME Validation Methods" IANA registry defined in RFC 8555.
A CA MUST ensure that its support for "accounturi" and "validationmethods" is fully consistent across all issuance systems for a given CA domain name. A CA unable to ensure consistency MUST NOT implement support for these parameters.
A Property with multiple "accounturi" parameters is unsatisfiable. A Property with an invalid or unrecognized "accounturi" parameter is also unsatisfiable.
CAs MUST still validate the domain name specified in an "issue" or "issuewild" record as described in RFC 8659, even when "accounturi" is present. The "accounturi" parameter does not replace domain name validation.
Each validation method label MUST be either a label from the "ACME Validation Methods" IANA registry or a CA-specific non-ACME label. Non-ACME CA-specific labels MUST begin with the string "ca-".
The value of the "accounturi" parameter MUST be a URI [RFC3986] identifying a specific CA account.
Because CAA records are publicly accessible, the "accounturi" parameter reveals authorized account URIs for a domain to any third party. This may allow correlation of domains that share the same account URIs. CAs are encouraged to select and process account URIs assuming untrusted third parties may learn of them.
An ACME account object MAY be identified by setting the "accounturi" parameter to the URI of the ACME account object. Implementations of this specification that also implement ACME MUST recognize such URIs.
The "accounturi" CAA parameter for the "issue" and "issuewild" Properties identifies a specific CA account by URI. A CA MUST only consider a Property with this parameter to authorize issuance if it recognizes the URI as identifying the requesting account.
The "validationmethods" CAA parameter for "issue" and "issuewild" Properties takes a comma-separated string of zero or more validation method labels. A CA MUST only consider the Property to authorize issuance when the validation method in use is identified by one of the listed labels.
A CA supporting "accounturi" or "validationmethods" MUST perform CAA validation using a trusted DNSSEC-validating resolver, where "trusted" means both trusting the resolver and securing the communications path between the resolver and the CA validation system.
All security considerations from RFC 8659 are inherited. This specification only constrains CAs that implement it; any other CA's capacity to issue certificates for the domain is completely unchanged, and domains remain vulnerable to CAs that do not honor CAA records.
Authorization freshness is a concern: a CA may establish account authorization substantially prior to issuance, during which the CAA policy may change. CAs SHOULD reduce this risk by using short-lived authorizations (e.g., one hour) or revalidating CAA policy at issuance time.
CAA records are not an effective way to restrict issuance for subdomains whose DNS control is delegated to another party, since CAA record lookup walks up the DNS hierarchy and subdelegation can supersede restrictions.
CAs MUST ensure that account URIs they recognize are unique within the scope of all domain names they recognize as identifying that CA for CAA validation, to prevent ambiguity when a CA uses multiple domain names. CAs SHOULD use URIs that include an authority component (e.g., "https://a.example.com/account/1234").
Misconfiguration of the "accounturi" and "validationmethods" parameters, which express restrictive policies, may result in legitimate issuance requests being refused.
These parameters are only effective if the CA named in the "issue" or "issuewild" Property recognizes and implements them. Domains MUST NOT assume the restrictions are effective without explicit confirmation from the CA that it supports these parameters.
These parameters do not provide additional security against global man-in-the-middle attackers unless the domain is signed with DNSSEC and the CA performs CAA validation via a trusted DNSSEC-validating resolver. Without DNSSEC, the parameters still provide administrative control over issuance.
The value of the "validationmethods" parameter MUST comply with ABNF: `value = [*(label ",") label]` and `label = 1*(ALPHA / DIGIT / "-")`, defining a comma-separated list of alphanumeric-plus-hyphen labels.