[cabfpub] Clarifying allowed wildcard in BR

Jeremy Rowley jeremy.rowley at digicert.com
Tue Mar 8 09:30:15 MST 2016


I agree it should be clarified, but I think we should add the text to
section 7.1.4.2.1 and state that a wildcard cert is any certificate
containing a wildcard character in a Subject Fully-Qualified Domain Name
contained in a Certificate. Plus, we have something in 7.1.4.2.1 called a
Wildcard FQDN that was never defined.



If we amend the definition as you suggested, fo*.example.com would no longer
be considered a wildcard certificate. Rather than prohibit issuance, the
change would exempt fo*.example.com from the wildcard rules in the BRs and
make it a normal string (because it doesn’t meet the wildcard definition).
To make it simple, I suggest:



Revise the definition of a wildcard certificate:

Wildcard Certificate: A Certificate containing an asterisk (*) in a Subject
Fully‐Qualified Domain Name contained in the Certificate.



Revise 7.1.4.2.1 as follows:

Contents: This extension MUST contain at least one entry. Each entry MUST be
either a dNSName containing the Fully‐Qualified Domain Name or an iPAddress
containing the IP address of a server. The CA MUST confirm that the
Applicant controls the Fully‐Qualified Domain Name or IP address or has
been granted the right to use it by the Domain Name Registrant or IP address
assignee, as appropriate. A dNSName entry MAY contain a wildcard character
provided that  the wildcard character constitutes the entire left most label
of the FQDN and only a single wildcard character is used in each FQDN.







From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Stephen Davidson
Sent: Tuesday, March 8, 2016 7:11 AM
To: public at cabforum.org
Subject: [cabfpub] Clarifying allowed wildcard in BR



Currently the BR address wildcard certificates as follows:



Wildcard Certificate: A Certificate containing an asterisk (*) in the left‐
most position of any of the Subject Fully‐Qualified Domain Names contained
in the Certificate.



The browsers implement this to mean “the asterisk must ONLY be in the left
‐most position and must constitute the ENTIRE label”.



That being said, there is some confusion among SSL buyers about what is
allowable.  This probably stems from RFC 6125 section 7.2 which first argues
against wildcards entirely, then recommends the use of the wildcard
character alone in the left-most label, but also acknowledges the other
historical wildcard variants found in other RFCs (such as HTTPS, LDAP, IMAP)
including:



fo*.example.com

*.*.example.com

www.*.example.com <http://www.*.example.com>



crt.sh/certlint (thanks Rob and Peter) finds a handful of examples of these
variants.  For the sake of clarity, I’d like to propose a simple amendment
to the wildcard definition in the BR to say:



Wildcard Certificate: A Certificate containing an asterisk (*) only in the
left‐most label, and constituting that entire label, of any of the Subject
Fully‐Qualified Domain Names contained in the Certificate.



Thoughts?  Anyone willing to join in proposing a ballot?



Regards, Stephen

QuoVadis

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160308/22c9eb92/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20160308/22c9eb92/attachment.bin 


More information about the Public mailing list