[cabf_validation] Authorization Email to Domain Contact

[Ryan Sleevi]

On Fri, Apr 13, 2018 at 4:45 PM, Doug Beattie <doug.beattie at globalsign.com>
wrote:

> Well, I was 0 for 4 on that one.  We’re attempting to come up with some
> new domain validation methods but it’s incredibly hard when we keep getting
> negative feedback without some concrete recommendations on what *would*
> work.
>
>    - What Opt-in mechanism are you referring to for the use of TXT
>    records?
>
> Because the issuance of a certificate is associated with a given FQDN, we
need to define what steps that administrator should take to protect
themselves - particularly at the authorization domain. Allowing any
_-prefixed label to be used means that the ADN operator MUST NOT allow any
third-parties to create any _-prefixed labels within the ADN, the FQDN, or
any label inbetween, as it may allow unauthorized issuance. We need to
close that gap.

One way to close that gap is to reform the singular existing method - .7 -
to use a defined label (_pki-validation). Then we're saying domain admins
only need to configuration that label to be restricted, much like they do
for admin@ or administrator@ (the CABF-invented emails).

However, you can only express one value at that label in a TXT record -or
you can put a CNAME (which means no other records, and can only point to
another domain with the same constraints) or a CAA record (which allows
multiple tag/values - see below). Thus, if we want to allow TXT records
(see even further below), we either need to define what the format of that
TXT record is (... similar to CAA), to support multiple different auth
methods, or we'd need to add another label, like
_pki-validation-through-email).

If we introduce another label, then every admin that blacklisted
_pki-validation labels is now at risk of _pki-validation-through-email
labels. This is the same as if we introduced a "certmaster@" email alias as
being permitted - every domain would immediately be at risk. One way to
mitigate that risk is to have the domain holder signal that they are aware
of those risks and have taken steps to protect themselves. A means of
expressing this (in a technically verifiable way, rather than something
silly and unrealistic like contracts) would be to define a parameter-tag
(... see below) to be placed in CAA that can indicate that, for a given CA,
the use of the _pki-validation-through-email label is permitted.


>
>    -
>    - What CAA semantics or approach are you recommending?  Can you give
>    an example?  I don’t understand how to permit or restrict subdomains with
>    the use of this new email address CAA record at the base domain without
>    needing to populate every subdomain record
>
> This one requires reading through RFC 6844 and understanding the design
concepts of CAA more.

You have two dimensions - one is the set of properties, which is a
combination of tag/value pairs, and presently includes the tags 'issue',
'issuewild', or 'iodef', each which have a defined value syntax.

The 'value' for an 'issue' property MUST include the domain (e.g. "
globalsign.com"), but also supports a set of CA-specific parameters, which
are themselves tag-value pairs. The CA is responsible for defining the
semantics of the 'tag' and 'value' here.

As to when you would choose to use a property-tag (all CAs) versus a
parameter-tag (single CA), one of the reasons is if you want to force a
given property-tag to be critical (i.e. "fail if you don't understand
this"). This is primarily useful when introducing more restrictive syntaxes
- such that 'bad things' would happen if they didn't understand and process
that critical property-tag.

An example of something that would be useful as a critical property-tag
would be a method for restricting the acceptable validation methods to a
defined subset. There, the domain holder may not wish to specify the
'issue' tag, but DOES want to make sure that any CA that issues observes
the semantics in the record.

With respect to subdomains, CAA has a defined processing algorithms, in
which subdomains are consulted first before the parent domain. Similarly,
the BRs define a tree-walking algorithm as part of the consideration of an
authorization domain name. In both of these models, the examination begins
at the most specific DNS label ("most subordinate"), and then walks 'up' to
the most generic record, the TLD (or the null domain). The problem with an
'allowSubdomains' semantic is that it inverts that processing model, by
requiring you start with the most generic domain, and then walk downwards
to the most specific label - checking each label along the way to see if
authority is allowed to 'flow'. Thus, an expression like 'allowSubdomains'
doesn't make sense, as the subordinate node operator (the one you're trying
to defend against) controls the domain that both CAA and the CA will start
with first, and thus they can always say 'allowSubdomains=yes', which
allows them to override whatever the parent node says. This design is
intentional, even if it may seem counter-intuitive.

As to the expression of e-mail addresses within CAA, that can either be
accomplished by a property-tag (CA independent) or a parameter-tag (CA
dependent). Having a property-tag like 'issueemail' (since it's ASCII
letters and numbers, all lower case) with a value of the email address is
one approach - but then you need to define semantics such as can that tag
appear multiple times (presumably, yes), how it interacts with
issue/issuewild, etc. Further, understanding how this method interacts with
or replaces other e-mail based verification methods is unclear.

Another approach is to define a parameter-tag (CA-specific), such that all
CAs can have defined semantics in the interpretation of this.


>
>    -
>    - If CNAME needs to point to a label that has a CAA record, then why
>    not use CAA directly?  I’m sure I’m missing the point.
>
> A few reasons. One for simple delegation of controls - something some CAs
have lamented about with the removal of .1. Another is the pragmatic
deployment concerns regarding the difficulty of deploying CAA records -
there may be operational reasons why a given domain uses a particular
domain serving infrastructure, and that may be limited or prohibited from
expressing CAA due to technical reasons, while supporting CNAME (or TXT, as
the BRs presently allow) - which you can then delegate to, say, a
'certificate management domain' hosted on a CAA-supporting infrastructure
or system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180413/98847ee1/attachment.html>