[cabfpub] Draft Ballot - Subject Common and Alternative Names

[Ryan Sleevi]

On Thu, Apr 14, 2016 at 12:02 PM, Peter Bowen <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:
>
> - Wildcards
>
> 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.
>

Further Context:

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, 3.2.2.6 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”, 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
> and 名がドメイン.com <http://xn--v8jxj3d1dzdz08w.com>.  So are
> 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.


>
> - SRVnames
>
> 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):
>
> 2616383605441589659_30145da21e420caa442070470707e1c3e538de18.blogspot.com:
>
> https://dns.google.com/query?name=2616383605441589659_30145da21e420caa442070470707e1c3e538de18.blogspot.com&type=A&dnssec=true
> dreamer_m.livejournal.com:
> https://dns.google.com/query?name=dreamer_m.livejournal.com&type=A&dnssec=true
> w3apps_rsatoken.conocophillips.com:
> https://dns.google.com/query?name=w3apps_rsatoken.conocophillips.com&type=A&dnssec=true
> ac_ccws.actx.edu:
> https://dns.google.com/query?name=ac_ccws.actx.edu&type=A&dnssec=true
>
> This proposed ballot allows these names.
>
> I hope that this explains the various proposed changes.
>

Further context:

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 "8.8.8.8" that resolved to "8.8.4.4",
which would be ambiguous and give different results than "8.8.8.8" 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160414/8159d924/attachment-0003.html>