[cabf_validation] Authorization Email to Domain Contact

[Doug Beattie]

I like most of the ideas proposed below.
- CAA: Excellent
- email in well-known: Good, assuming we can agree on parsing rules
- TXT record: Good, assuming we can come up with an agreed-to format for the TXT record
- CNAME: don’t like it at all

See more comments inline below


> -----Original Message-----
> From: Validation [mailto:validation-bounces at cabforum.org] On Behalf Of
> >
> >> 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.

For CAA, it seems we can come up with an approach, probably the preferred approach, for allowing a domain owner to enter an email address which will be used as the recipient of the challenge.

We might want to default to only that domain being authorized and suggest a flag "allowSubdomains" which would permit this to be used to approve subdomains and wildcard certificates.  Is that reasonable/desired?

This would permit the email address to be used for only example.com:
      example.com.  domainEmail 0 example at example.com

This would allow the email address to be used to approve any/all subdomains of example.com, including example.com
      example.com.  domainEmail 0 example at example.com "allowSubdomains"


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

If we use TXT records that contain _pki-validation followed by the email address, is that sufficient structure that DNS admins could limit who can create such records (assuming that is the risk).  For instance:
   _pki-validation example at example.com

We also need to discuss if this can be used for wildcards or subdomains.  Maybe we need another field to signal that "allowSubdomains", "allowWildcard"
  _pki-validation example at example.com "allowSubdomains"

I think this is a good idea.

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

I'm not a fan of using CNAME to specify email addresses.  We already have TXT and CAA, do we need a 3rd DNS method?

> 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].

Don’t we have the same parsing problem now pulling email addresses from who-is?  Regardless, if we can get around that, do we agree that putting an email address in a specific (standardized) file name in the /.well-known/pki-validation directory, is that an acceptable approach?  Bruce suggested the file name auth-email.txt.     It sounds good to me.


> Kind regards
> Quirin
> 
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://cabforum.org/mailman/listinfo/validation