[Servercert-wg] Question on BR 3.2.2.6

[Doug Beattie]

Ryan,

 

Your statement below: “ .. 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…” doesn’t align with what the BRs, section 7.5.1 says: “(a) For each dNSName in permittedSubtrees, the CA MUST confirm that the Applicant has registered the dNSName or has been authorized by the domain registrant to act on the registrant's behalf in line with the verification practices of section 3.2.2.4.”.

 

There seems to be a disconnect, because the way I read this is that the BRs permit any method to be used, not just DNS.  Are you proposing a change to the BRs?  If there is the possibility of multiple interpretations, then we’ll want to address this section as part of the Default Allow/Default Deny discussion in the Validation subcommittee. 

 

Doug

 

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Servercert-wg
Sent: Thursday, February 27, 2020 11:45 AM
To: Pedro FUENTES <pfuentes at wisekey.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] Question on BR 3.2.2.6

 

 

 

On Thu, Feb 27, 2020 at 9:45 AM Pedro FUENTES via Servercert-wg <servercert-wg at cabforum.org <mailto: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/20200228/1f22727a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5701 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200228/1f22727a/attachment.p7s>