[cabfpub] Draft Ballot - Subject Common and Alternative Names

Peter Bowen pzb at amzn.com
Fri Apr 8 16:15:15 MST 2016


For your consideration, here is a draft ballot addressing what is allowed in common and alternative names for server authentication certificates.  I’ll work on a GitHub PR for these changes in the next few days.

Dean: Can you please add a slot for discussion of this ballot to the agenda for the next meeting?

Thanks,
Peter

---- BEGIN BALLOT ----

Whereas the requirements for Wildcard names in certificates have not been clearly defined, and

Whereas representation of internationalized domain names in common name attributes has not been clearly defined, and

Whereas multiple common name attributes in subjects are known to cause unexpected client behavior, and

Whereas SRVNames help improve the security of certificates and have a globally managed namespace, and

Whereas ICANN has recognized and formalized .brand gTLDs in which domains are managed by a single entity, and

Whereas many users utilize host names containing the underscore character,

Therefore, be it resolved, effective the date of passage, the following modifications to the Baseline Requirements are adopted:

In Section 1.6.1:
- In the definition of "Wildcard Certificate", replace "an asterisk (*) in the left‐most position of any of the Subject Fully‐Qualified Domain Names" with "a Wildcard Domain Name in any of the Subject Alternative Name dNSNames";
- Insert a new definition: "Wildcard Domain Name: A Domain Name formed by prepending '*.' to a FQDN"

In section 3.2.2.6:
- Replace "wildcard character (*)" with "Wildcard Domain Name";
- Replace "wildcard character occurs in the first label position to the left of" with "FQDN portion of the Wildcard Domain Name is";
- Replace "a wildcard would fall within the label immediately to the left of a registry‐controlled† or public suffix," with "so,";
- Replace '“*.example.com” to Example Co.' with '“*.example” if the .example gTLD includes Specification 13 in its registry agreement'.

In section 7.1.4.2.1, replace the first paragraph of the contents with:

"This extension MUST contain at least one entry.  Each entry MUST be one of a dNSName containing a Fully Qualified Domain Name or Wildcard Domain Name, an iPAddress containing an IP address, or an otherName of type SRVName as defined in RFC4985.  The CA MUST confirm that the Applicant controls the Fully‐Qualified Domain Name (including the Name portion of the SRVName) or IP address or has been granted the right to request a certificate for it by the Domain Name Registrant or IP address assignee, as appropriate. 
As exceptions to RFC5280 and X.509, Wildcard Domain Names are permitted in dNSName entries and the underscore character ("_") is permitted in FQDNs and Wildcard Domain Names in any location where the hyphen character ("-") is allowed. Wildcard Domain Names are not allowed in SRVName entries.

If a name constrained CA has a dNSName constraint but does not have a constraint for SRVNames, the CA MUST NOT issue certificates containing SRVNames where the Name portion is in an excluded dNSName subtree.  Such a CA also MUST NOT issue certificates containing SRVNames where the Name portion is not in a permitted dNSName subtree if at least one permitted dNSName subtree exists."

In section 7.1.4.2.2(a), append the following sentences to "Contents": 

'If the value from the subjectAltName extension contains at least one label that starts with "xn--" (an "A-label"), this field may contain the Unicode encoding of the A-labels (an "U-label"), provided that all A-labels in the value are converted to U-labels. There MUST NOT be more than one commonName attribute in the Subject Distinguished Name.’

---- END BALLOT ----


More information about the Public mailing list