[Servercert-wg] Question on BR 3.2.2.6

Adriano Santoni adriano.santoni at staff.aruba.it
Thu Feb 27 08:17:52 MST 2020


Pedro,

in a CA certificate, one would not insert a wildcard in Name 
Constraints, as it's not needed (per 
https://tools.ietf.org/html/rfc5280#section-4.2.1.10) and probably not 
even allowed, although RFC5280 does not explicitly forbid it. In your 
example, it would suffice to include "*gov.XX*".

That said, I understand that domain control validation for domains 
listed in a CA certificate (in the Name Constraints extension) must be 
done by the same methods used for Subscriber certificates, per BR 
3.2.2.4 (see the "*Note*" before 3.2.2.4.1).

Adriano


Il 27/02/2020 15:44, Pedro FUENTES via Servercert-wg ha scritto:
> 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”.
>
> 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)?
>
> I’d appreciate to be enlightened with positive comments on the above.
>
> Thanks,
> Pedro
>
> *WISeKey SA
> *
> *Pedro Fuentes
> *CSO - PM eSecurity Solutions
> Office: + 41 (0) 22 594 30 00
> Mobile: + 41 (0) 791 274 790
> Address: 29, Rte de Pré-Bois - CP 853 | Geneva 1215 CH - Switzerland
> *Stay connected with WISeKey <http://www.wisekey.com>
> *
> *
> *
> *CONFIDENTIALITY: *This email and any files transmitted with it can be 
> confidential and it’s intended solely for the use of the individual or 
> entity to which they are addressed. If you are not the named addressee 
> you should not disseminate, distribute or copy this e-mail. If 
> you have received this email in error please notify the sender
>
> *DISCLAIMER: *WISeKey does not warrant the accuracy or completeness of 
> this message and does not accept any liability for any errors or 
> omissions herein as this message has been transmitted over a public 
> network. Internet communications cannot be guaranteed to be secure or 
> error-free as information may be intercepted, corrupted, or contain 
> viruses. Attachments to this e-mail are checked for viruses; 
> however, we do not accept any liability for any damage sustained by 
> viruses and therefore you are kindly requested to check for viruses 
> upon receipt.
>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200227/c9f58048/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4105 bytes
Desc: Firma crittografica S/MIME
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200227/c9f58048/attachment-0001.p7s>


More information about the Servercert-wg mailing list