Summary

  • RFC 8657 lets a CAA issue or issuewild property narrow authorization to a recognized account URI and one or more recognized validation methods; those parameters supplement rather than replace the CA identifying domain.
  • Recognition is optional and CA-specific, but every issuance system using the same CA identifying domain must recognize supported parameters consistently. A CA that cannot align its systems can use separate identifying domains.
  • A correct restrictive property can still be defeated by another applicable permissive CAA property, and tightening DNS later does not revoke certificates already issued.

Imagine an acquisition in which three certificate-issuance channels will keep operating: a current ACME service, an internal managed-certificate platform and a legacy enterprise interface. All three are expected to appear under one familiar CA name in customer CAA records. The integration deck calls this consolidation. The DNS record asks a more exact question: will the same account and method restrictions mean the same thing at all three doors?

CAA begins with issuance authority, not certificate validity. RFC 8659 defines how an issuer searches for the relevant RRset and evaluates issue or issuewild properties for each requested name. The result tells a conforming CA whether it is authorized to issue now. It does not tell browsers to reject an existing certificate, and a later DNS change does not itself revoke one.

RFC 8657 adds two parameters to that decision. A recognized accounturi binds the containing property to the requesting account identified by the URI. The property still has to match the CA identifying domain. With no account parameter, any account may satisfy that property. With several account parameters, an invalid value, or a value the issuer does not recognize, the property cannot authorize the request.

The URI is public identification, not a password. An ACME implementation that supports the extension recognizes the URI of an ACME account object. A non-ACME system may assign another URI. Possession of the string is not possession of the account credential, and copying it to another CA does not carry authority with it.

validationmethods narrows the same property to one of the named methods. Its list is comma-separated, and an empty list names no permitted method. The IANA registry supplies ACME labels; a non-ACME channel may require labels defined by the CA. A method name in DNS therefore has force only where the named issuer has said it recognizes that parameter and value.

That qualification is deliberate. Parameter recognition is optional and specific to the CA. Domain holders are told not to assume a restriction works merely because the syntax is valid. The issuer needs an explicit support statement. Let's Encrypt, for example, publicly documents letsencrypt.org, its account-URI form and the http-01, dns-01 and tls-alpn-01 labels it recognizes. That is useful operational evidence about one documented service, not an audit of every path or proof of universal adoption.

The organisational boundary appears in RFC 8657's consistency rule. All issuance systems that use one CA identifying domain must recognize the same parameters consistently. The text explicitly anticipates ACME and non-ACME systems, and systems brought together through a merger. If the organisation cannot make their interpretations compatible, it may allocate separate CA identifying domains. It must not claim support under one identifier while leaving a path that gives the restriction a different meaning.

Consistency does not require unrelated CAs to share an account database. It does require account URIs to be unambiguous across the CA identifying domains that one CA recognizes, including namespaces brought together in a merger. URIs with an authority component are recommended because a bare local number can collide when two systems both have an account 1042.

There is a second trap outside the issuer's parser. CAA authorizations are additive. A domain can publish one property that restricts issuance to a named account and another applicable property that authorizes the same CA without that restriction. The narrow line does not cancel the broad one. Wildcard requests add another branch: where issuewild exists, it governs wildcard issuance and issue is ignored for that request; ordinary names still use issue.

The critical flag does not fix this. Its meaning concerns an unknown or unsupported property tag. Setting it on issue cannot force recognition of an unfamiliar accounturi or validationmethods parameter. Treating the flag as a universal “strict mode” confuses the property tag with its parameters.

Time separates authorization from outcome as well. A CA may validate control and issue later. RFC 8657 discusses shorter authorization lifetimes and checking CAA again near issuance as ways to reduce that interval, but its roughly one-hour example is not a universal deadline. Even after a restrictive record replaces a permissive one, certificates issued during the earlier window may remain valid.

DNS resolution remains part of the control surface. The CA must use a trusted DNSSEC-validating resolver and protect the path to it when implementing these parameters. CAA lookup follows aliases during the CAA query, walks upward until the first non-empty RRset and evaluates every requested name. A delegated subdomain can therefore establish a different policy, and a mistaken restriction can block legitimate renewal.

The evidence sentence should be narrow: “this issuing path evaluated this relevant CAA RRset, matched this CA identifier, recognized this account URI and method, and admitted this request at this time.” A common logo, a valid URI, a critical bit or one successful renewal cannot substitute for that record across the other systems.

Sources

  1. RFC 8657 — Certification Authority Authorization Record Extensions for Account URI and ACME Method Binding
  2. RFC 8659 — DNS Certification Authority Authorization Resource Record
  3. Let's Encrypt — CAA documentation
  4. Heng Lu — On the agency problem at the core of Internet governance
  5. Heng Lu — On why BTW Media exists and why reality, not advocacy, is the product