[cabf_validation] Authorization Email to Domain Contact

[Quirin Scheitle]

Hi Ryan,

thank you for your reply! 

> On 12. Apr 2018, at 19:43, Ryan Sleevi <sleevi at google.com> wrote:
> 
> 
> 
>> 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'?).

Yes. I would think that if it is properly defined in some document, “dcvemail” is understandable, but happy to use something else.

> 
> 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)
>  

All agreed, 1) is a very good point, selection of that prefix should be done very carefully with regards to other existing prefixes.

>> 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 =)

Well, I guess one could encode email addresses similar to SOA RNAMEs, but I am really not a fan of that.

Similar to you, I am not enthusiastic about further abuse of CNAME or TXT, but if we must keep supporting it for some reason [e.g. still lacking CAA support at large DNS operators] I guess it is doable. 
If we get rid of CNAME and TXT, we also do not need the _SOMETHING prefix any more (at least for this purpose).

>  
> 
> > 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)? 

Good points. I intentionally said this on high level as I lack experience in the typically used definitions of a “sound” email-address :) 
[I guess CAs must have some e-mail soundness checking script for current e-mail validation methods].

Kind regards
Quirin