[cabfpub] Draft Ballot - Subject Common and Alternative Names
kirk_hall at trendmicro.com
kirk_hall at trendmicro.com
Thu Apr 14 23:26:24 UTC 2016
Thanks, Peter and Ryan. This context will really help everyone understand the draft ballot much faster.
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi
Sent: Thursday, April 14, 2016 1:00 PM
To: Peter Bowen
Subject: Re: [cabfpub] Draft Ballot - Subject Common and Alternative Names
On Thu, Apr 14, 2016 at 12:02 PM, Peter Bowen <pzb at amzn.com<mailto:pzb at amzn.com>> wrote:
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<http://example.com>” is allowed by “fin*.example.com<http://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.
There's two definitions in the BRs today, which caused the confusion:
v1.3.4, p9, 1.6.1, 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.
v1.3.4, p14, 126.96.36.199 Before issuing a certificate with a wildcard character (*) in a CN or subjectAltName of type DNS‐ID, the CA MUST establish and follow a documented procedure† that determines if the wildcard character occurs in the first label position to the left of a “registry‐controlled” label or “public suffix” (e.g. “*.com”, “*.co.uk<http://co.uk>”, see RFC 6454 Section 8.2 for further explanation).
The inconsistency between the terminology ("the wildcard occurs in the first label position", "left-most position") is what causes the confusion. Some CAs have apparently read "left-most position" as "left-most label" (but any character within that label), while others have read it as "left-most character of the left-most label". The latter interpretation is supported by RFC6125's recommendations, and the implementations of Chrome and Firefox, but the former interpretation is part of the liberalness of the variety of predecessor specs that RFC 6125 was meant to clarify as BCP
- 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<http://v8jxj3d1dzdz08w.com> and 名がドメイン.com<http://xn--v8jxj3d1dzdz08w.com>. So are xn--detrsbonsdomaines-vsb.com<http://xn--detrsbonsdomaines-vsb.com> and detrèsbonsdomaines.com<http://xn--detrsbonsdomaines-vsb.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.
Further context: Only the xn-- form is allowed in the SAN because the dNSName is IA5String (And Section 7 covers a bit more of the internationalization issue), while commonName comes from X.520 and is a CHOICE of (TeletexString, PrintableString, UniversalString, UTF8String, BMPString) of up to 64 characters (... not bytes).
One potential issue here is with respect to the IDNA policies and presentation. You have two different policies here (IDNA2003 v IDNA2008), which can go to different domains, as well as display policies (for example, Chrome and Firefox have different policies as to when to display a domain name in A-Label vs U-Label form). https://wiki.mozilla.org/IDN_Display_Algorithm captures some summary, but Mozilla hasn't kept that up to date, and we've updated our implementation but not updated http://www.chromium.org/developers/design-documents/idn-in-google-chrome yet.
I'm a big believer in only using the A-label form (aka the xn-- form), and letting applications determine whether to display the U-Label based on their application policies. The risk here is that you can have a common name that claims to be one domain, but the browser presents the domain in the URL bar in another form, and I think that's a reasonable concern.
- 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.
Alternatively, it'd be useful to understand if this can be removed, much as we've removed provisions such as issuing directly from a root or longer than 60 months. Note that the use of the commonName was already deprecated during the publication of RFC 2818 (HTTPS), 16 years ago.
A SRVname is a type of subject alternative name that has both a DNS name (us.example.com<http://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.
These domains are invalid according to RFC 1034's preferred name syntax, and as updated by RFC 1123. Here, the term "hostname" - that is, a domain name with an A label associated - has a defined format of "the LDH rule" - for Letter, Digit, Hyphen. While other DNS records exist (for example, SRV, TXT, and CAA), and those DNS records can have their own format rules (for example, SRV makes heavy use of a leading _ precisely because it avoids the ambiguity with A records), the A/AAAA notion of "hosts" has a specific format. The LDH rule of RFC 1034 was designed to avoid ambiguity with IP addresses - for example, it required a letter in the first label, so that you couldn't have a valid DNS name of "188.8.131.52" that resolved to "184.108.40.206", which would be ambiguous and give different results than "220.127.116.11" the IP address. RFC 1123 relaxed this rule, on the basis that there would never be a valid ".8" TLD, because the IANA registration of TLDs (since outsourced to ICANN with respect to gTLDs, although IANA maintains ultimate responsibility for the root zone) would never allow a purely numeric TLD (like .8).
As Peter mentioned, this is all in the context of A/AAAA records. The DNS wire protocol itself is 8-bit, although domains (not hosts - that is, things with A/AAAA) are recommended to be 7-bit to avoid compatability issues. However, that's not strictly required.
For example, RFC 1034/1123 also address things like case-sensitivity; the DNS wire protocol is case-sensitive (because it's arbitrary octets), while the host resolution (A/AAAA) is not, and in general, very few records are.
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential
and may be subject to copyright or other intellectual property protection.
If you are not the intended recipient, you are not authorized to use or
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public