[cabf_validation] Designated Authorization Domain Label (method F) write-up

[Corey Bonnell]

I wrote up a preliminary “ballot text” for Method F (using a subdomain to function as an Authorization Domain Name for a FQDN) as defined in the Validation Summit Findings document.

Since this proposed change increases the number of ADNs, I believe that explicit opt-in is required so that the ecosystem is not negatively affected if this method is allowed. The mechanism chosen is a DNS TXT record with a specific syntax for the RDATA value. Using DNS TXT over another record type has three advantages:

  1.  There is precedent for this syntax, as DKIM and SPF records use a very similar syntax.
  2.  TXT is a universally supported record type, unlike other alternatives.
  3.  TXT has an advantage over CAA in that the presence of TXT records at a specific Domain Name does not halt CAA tree-climbing and does not invert the CAA restriction model. The current CAA tree-climbing logic indicates that tree-climbing for records stops upon encountering a non-empty CAA record set. This means that, if in the course of CAA processing, a non-empty CAA record set is encountered that contains only property tags which signal allowed domain validation methods but otherwise does not contain any issue/issuewild records which restrict the set of CAs that are allowed to issue, then any CA can issue for that domain. If the domain owner wishes to both restrict domain validation methods AND restrict the set of allowed CAs, they must repeat these records at every subdomain that may be used as an ADN if any CAA record differs from the CAA records at a parent Domain Name. In addition, the CAA tree-climbing process (which starts at the most specific Domain Name) is the inverse of ADN processing (where authorization is top-down), creating an impedance mismatch that is both difficult to comprehend and is error-prone for domain owners. As such, TXT records were selected as the preferred mechanism to opt-in for Method F.

This proposed method allows domain owners to create a special TXT record at a FQDN to signal that a specific subdomain (called the “DADL”, or “Designated Authorization Domain Label”) is allowed to be an Authorization Domain Name of the FQDN.

Assume a domain owner owns “example.com”. For operational reasons, they cannot use any of the accepted domain validation methods directly against “example.com”, but they can provision a web server at “_pki-validation.example.com” to perform domain validation. As such, they create a TXT record at “example.com” to designate “_pki-validation” as the DADL for “example.com”:
example.com. IN TXT “v=DADL1; l=_pki-validation”

There is an initial overhead in creating the TXT record at example.com, but moving forward the domain owner can use the _pki-validation subdomain for domain validation.

There is also support for DADLs at aliases. Assume that “example.thecdn.com” is an alias for “example.com”. If the domain owner for “example.com” wishes to use “_pki-validation.example.thecdn.com” as the ADN, they can create the following TXT record at “example.thecdn.com”:
example.thecdn.com. IN TXT “v=DADL1; l=_pki-validation”

Note that the current algorithm I have below does not permit the DADL to itself have an alias. This was done to keep the number of ADNs reasonable, but we may determine that allowing aliases in this case is desirable.

Also, method 7 (DNS change) allows for an arbitrary subdomain which starts with an underscore to function as the ADN for a given FQDN. This means that in combination with the DADL, a sub-sub-domain of the FQDN can be allowed as the ADN. This has undesirable security properties, so I imagine we’d want to restrict that. However, I don’t address this situation, as we discussed restricting method 7 at the Validation Summit. I can modify this ballot text when we determine what to do about method 7.

Without further ado:

Modify the following to BR 1.6.1 Definition:

Authorization Domain Name: The Domain Name used to obtain authorization for certificate issuance for a given FQDN, which is determined using the following algorithm:
Let PARENT(X) be the parent Domain Name of X. The parent Domain Name is determined by removing the leftmost label of X.
            Let NOWILD(X) be PARENT(X) if X starts with “*.” (Unicode U+002A ASTERISK and U+002E FULL STOP). If X does not start with “*.”, then NOWILD(X) is X.
            Let ALIAS(X) be the target of DNS alias chasing at X. If there is no alias for X, then ALIAS(X) is NIL.
            Let DADL(X) be the result of performing the following algorithm:

  1.  Perform a DNS TXT lookup at X.
  2.  For each TXT record in the retrieved Resource Record Set from step 1, check that the record’s RDATA string matches the following ABNF grammar (as per RFC 5234):
rdata = “v=DADL1;” *WSP “l=” label [“;”]
label = “_” (ALPHA / DIGIT) *( *"-" (ALPHA / DIGIT))

  1.  If there is a match found in step 2, then DADL(X) is the concatenation of the “label” value, Unicode U+002E FULL STOP character (“.”), and X. If there is no such match for any retrieved TXT records, then DADL(X) is NIL.


  1.  Let X be the FQDN to be validated.
  2.  Let X’ be the result of NOWILD(X).
  3.  Add X’ to the set of candidate Domain Names.
  4.  Let A be the result of ALIAS(X’).
     *   If A is not NIL, then:
                                                                          i.       Add A to the set of candidate Domain Names.
                                                                         ii.      If DADL(A) is not NIL, then add DADL(A) to the set of candidate Domain Names.

     *   If A is NIL and DADL(X’) is not NIL, then add DADL(X’) to the set of candidate Domain Names.
  1.  If X’ is not a Base Domain Name, then repeat steps 3-5 with PARENT(X’) as X’.
  2.  Select a Domain Name from the set of candidate Domain Names.



Corey Bonnell
Senior Software Engineer
t: +1 412.395.2233

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com<http://www.trustwave.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180424/c39596ee/attachment-0001.html>