[Servercert-wg] Question on BR 3.2.2.6

[Ryan Sleevi]

On Thu, Feb 27, 2020 at 9:45 AM Pedro FUENTES via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> Dear all,
> Sorry if this is not the appropriate way to do things, but I’m a newbie in
> the Forum, so please be indulgent.
>
> BR 3.2.2.6 says:
> *“If a wildcard would fall within the label immediately to the left of a
> registry-controlled1 or public suffix, CAs MUST refuse issuance unless the
> applicant proves its rightful control of the entire Domain Namespace.
> (e.g. CAs MUST NOT issue “*.co.uk <http://co.uk>” or “*.local”, but MAY
> issue “*.example.com <http://example.com>” to Example Co.).”*
>
> I’ll have a comment and a question regarding the above...
>
> Comment: In my humble opinion, the wording of that paragraph seems
> incorrect, as a “MUST” or "MUST NOT” that is conditioned to certain
> exceptions seem more appropriate to be stated as “SHOULD” or “SHOULD NOT”.
>

Unfortunately, under RFC 2119/BCP 14, that would imply there are other
(unstated) exceptions or reasons to ignore that requirement. MUST is
defined as the requirement is absolute.


>
> Question: Considering the allowed exception (*“unless the
> applicant proves its rightful control of the entire Domain Namespace”*),
> and *in particular thinking on a wildcard of the type “*.gov.XX” used as
> a name constraint in a CA certificate (and not for a wildcard TLS
> certificate)*... Has been discussed in the past what is an acceptable
> method to prove this control? Would any method allowed by BR 3.2.2.4 be
> enough (e.g. agreed change in DNS)?
>

As Adriano mentioned, a wildcard doesn't appear in the nameConstraints
field. That said, demonstration of the total control of the namespace would
definitely tie to a validation based on DNS, as opposed to a validation
limited in scope, for example, the /.well-known/ method (which only
validates a host), a TLS-based method, or an IP address. Any change that
requires a modification to the DNS itself to complete, which would include
the CAA methods, should be defensible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200227/4a5ecd5b/attachment-0001.html>