[cabf_validation] Authorization Email to Domain Contact
doug.beattie at globalsign.com
Fri Apr 13 12:38:34 MST 2018
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'
> > Is sleevi at email@example.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
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
> Validation mailing list
> Validation at cabforum.org
More information about the Validation