The ACME-CAA draft extends the base CAA mechanism described by RFC 6844 to
allow fine-grained authorization for draft-ACME based CAs. It adds two new
parameters to the "issue" property tag, and the "issuewild" property tag. The
new parameters are "accounturi" and "acceptedchallenges" and can be used to
extend a CAA policy for an ACME based CA.
The "accounturi" parameter allows the domain holder to restrict authorization
to issue for a domain to only the ACME account URI specified in the CAA
policy. The "acceptedchallenges" parameter allows the domain holder to restrict
the ACME challenges that can be used for domain validation of a domain to those
specified in the CAA policy.
Working Group Summary
Earlier drafts used a hyphen character in the "validationmethods" and
"accounturi" parameters that was incompatible with the grammar defined in RFC
6844. This has been addressed in the latest draft by removing the hyphen
Early discussion of the draft addressed issues raised by the community with
regards to the security considerations section, and the handling of non-ACME
challenge methods. Overall consensus was reached within the WG process without
any rough areas and no controversial topics remain unaddressed.
Let's Encrypt, a large high-volume production ACME based CA, has fully
implemented the ACME-CAA draft in a testing environment (not yet promoted to
production usage). Let's Encrypt has committed to promoting ACME-CAA features
to production in the near future.
The overall document quality is high. Developing an implementation based on the
specification text is reasonable.
The document shepard is Daniel McCarney. The responsible area director is Eric
There are no IANA considerations and no IANA experts/registry work is required.