[cabfpub] Draft Ballot - Subject Common and Alternative Names
pzb at amzn.com
Thu Apr 14 19:02:03 UTC 2016
On today’s CAB Forum call there was a request to clarify some of the background of this proposed ballot. Addressing each of the items:
The current BRs say "wildcard character occurs in the first label position”. This has been interpreted to mean that the wildcard character (an asterisk) is the only character in the first label or is anywhere in the label. This proposed ballot makes it clear that the only the former is allowable. So “*.example.com” is allowed by “fin*.example.com” is not. It also makes it clear that Wildcard names are allowed even though the RFCs and X.509 may not allow such.
- IDNs in Common Names
Internationalized Domain Names have two forms. One form starts with “xn--" and only contains letters, numbers and hyphens. The other form has support for a wide range of characters. For example xn—v8jxj3d1dzdz08w.com and 名がドメイン.com. So are xn--detrsbonsdomaines-vsb.com and detrèsbonsdomaines.com. Only the xn-- form is allowed in Subject Alternative Name (SAN) entries and the BRs require the Common Name to be one of the SAN entries. It is not stated which form must be used for Common Names. My proposal is to allow either form in common name.
- Multiple Common Name attributes
A distinguished name can contain unlimited attributes of the same type (e.g. 10 different countries or common names). However, as was pointed out in 2009 (http://www.ioactive.com/pdfs/PKILayerCake.pdf), different implementations handle multiple common names inconsistently. This can result in names not being validated on the CA end and unexpected errors on the client. As the BRs already note that common name is deprecated for server certs, reducing confusion by limiting to one common name seems to make sense.
A SRVname is a type of subject alternative name that has both a DNS name (us.example.com) and a service/protocol (smtp). This allows a certificate to be issued for only one protocol. It is not widely used today, but this is likely because CAs are not allowed to issue certificates with SRVnames. This proposed ballot allows CAs to include SRVnames in certificates.
- .brand gTLDs
A number of the new global top level domains (gTLDs) are “.brand” TLDs where all domains under the TLD will be controlled by a single company. ICANN refers to these as specification 13 gTLDs. They maintain a list of them online: https://newgtlds.icann.org/en/applicants/agb/base-agreement-contracting/specification-13-applications This updates the example of where an applicant might control a whole domain namespace to reference spec 13.
- Underscores in hostnames
Recent X.509 Corrigendum and RFC 5280 require that DNSname type entries in SANs only contain A-Z, 0-9, hyphens and periods. The DNS protocol can handle other characters and many common systems allow a slightly broader set of characters, notably adding underscore as an allowable character. A few examples (using Google’s web DNS resolver):
This proposed ballot allows these names.
I hope that this explains the various proposed changes.
> On Apr 8, 2016, at 4:15 PM, Peter Bowen <pzb at amzn.com> wrote:
> 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?
> ---- 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 18.104.22.168:
> - 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 22.214.171.124.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 126.96.36.199.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 ----
> Public mailing list
> Public at cabforum.org
More information about the Public