[cabf_validation] Authorization Email to Domain Contact

[Ryan Sleevi]

On Thu, Apr 12, 2018 at 1:30 PM, Quirin Scheitle <scheitle at net.in.tum.de>
wrote:

> The record to be looked up could be the subdomain _dcv or the main domain
> (i.e., the domain name to be validated). The main domain is certainly a bad
> idea for CNAME, and maybe for TXT.
> For CAA, I think the main domain could be used.
> For CAA, I propose the tag “dcvemail” with the value of the format “
> abc at example.com”


I'm not a fan of overly abbreviated things (I'm guessing you're trying for
'domain control validation'?).

With respect to the introduction of any form of
subdomain-suitable-for-the-base-domain, we have the same problem as the
introduction of additional constructed email addresses or validation paths
(outside of /.well-known/pki-validation) any introduction of a new
subdomains breaks any blacklisting solution, and due to the architecture of
today (of email, of DNS, of websites), blacklisting is unfortunately the
only solution available.

Thus, I think there's several preconditions at play here:
1) We need to restrict the underscore prefix usable for existing methods
(e.g. "_pki-validation" as the Only Acceptable Label)
2) If we're going to keep abusing TXT records, rather than switching to CAA
as we should, we need to define a semantically meaningful format to
disambiguate between multiple methods that may wish to allow them
3) If we're going to introduce new methods of delegating authority, we need
to consider making them as whitelisted (e.g. explicit opt-in to permit that
validation method, via CAA) rather than forcing opt-out (making everyone
default at-risk)


> For CNAME, I guess one could make it contain an e-mail address, although
> it certainly is odd.
>

How? The CNAME contains a host name =)


>
> > Is "auth-email.txt" a directory, or a file? What is the format of this
> file? How do you ensure that the e-mail is unambiguously parsed from this
> file?
>
> My intuition would be to make it a file, which solely contains an e-mail
> address in ASCII.
> If it is unparseable, contains weird characters, or extra information, it
> is not to be used.
>

Right, and more specification there is needed as to what 'unparseable'
means.

Is sleevi at google.com@sleevi.com unparseable? What about "sleevi at google.com"@
sleevi.com?
Is (UTF-8 sequence)@google.com unparseable (it's an EAI)?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180412/f78c61be/attachment.html>