[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