[cabf_validation] ACME DNS-01 "Authorization Domain Name" conflict

[J.C. Jones]

All,

I apologize for not catching this myself: After wider publication of the
draft this morning, a community member brought up concerns about the
definition of "Authorization Domain Name" and its label processing in
regards to ACME's DNS-01 challenge. Particularly, there is concern that
since the label processing begins from the FQDN, that it prohibits the
ACME-defined marker label being prepended to the FQDN in the record.

As an example, to demonstrate control of "example.com" via DNS-01, one
would provision a DNS leaf record such as:

   _acme-challenge.example.com. 300 IN TXT "gfj9Xq...Rg85nM"

... where the record body is a Random Value.

(While in general <something>.FQDN does not imply control of FQDN, the ACME
design's use of the underscore prefix is thought to mitigate the practical
control concerns.)

One possible resolution would be to append to the first paragraph of
section 3.2.2.4.7. "DNS Change" (addition in []s):


> Confirming the Applicant's control over the requested FQDN by confirming
the presence of a Random Value or Request Token in a DNS TXT or CAA record
for an Authorization Domain Name [[, or a leaf record of the Authorization
Domain Name which begins with an underscore character]].


Currently there is no central directory of underscore-prefix names such as
there is for the .well-known/ URI path, though there is a draft [1] adopted
by the DNSOP WG at IETF [2], so in theory this could be revised in the
future to require the use of registered leaf records only.

Can we consider adding this text, or in some other way addressing this,
before presenting a ballot?

Finally, thank you to both Andrew Ayer and Peter Bowen who recognized this
issue and helped me research it.

1) https://trac.tools.ietf.org/id/draft-crocker-dns-attrleaf-07.html
2) https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/

J.C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/validation/attachments/20160413/0c18d1e4/attachment.html