On Wed, Nov 18, 2015 at 10:25 AM, Ryan Sleevi
<ryan-mozdevsecpol...@sleevi.com> wrote:
> On Wed, November 18, 2015 8:56 am, Peter Bowen wrote:
>>  On Wed, Nov 18, 2015 at 2:22 AM, Rob Stradling <rob.stradl...@comodo.com>
>>  wrote:
>> > I would also like to get clarification on if/when the underscore
>> > character
>> > may be used in each of the name types.  Your report seems to flag
>> > underscores as always prohibited (I think), but I expect that some CAs
>> > would
>> > be surprised by that.
>>  Here is a set of rules that are functionally equivalent to the ones
>>  I'm using to check dNSNames in GeneralNames:
>>  LABEL = "((?!-)[A-Za-z0-9-]{1,63}(?<!-))"
>>  FQDN = "(#{LABEL}\.)*#{LABEL}"
>>  WILDCARD_DN = "\\*\\.#{FQDN}"
>>  dNSName =~ /\A#{DNSNAME}\z/
>>  The FQDN rule is based on RFC 5280 section, which in turn
>>  references RFCs 1123 and 1034.  There is no allowance for underscores
>>  in domain names in these RFCs.
> You've entered a special hell. It is dark and scary. You are likely to be
> eaten by a grue.
> The world is an awful place. Hostnames, doubly so.

> Now let's get messier yet still. 1034 introduces the "Preferred Name
> Syntax", which is a recommendation for how to encode names. For example,
> one part is that it suggests that all labels start with at least one
> letter. This is to avoid ambiguity when parsing IPs, since if labels could
> be all numeric (, then it could be ambiguous as to how to parse
> as a host name versus an IP address. However, 1123, Section 2.1, relaxed
> this to allow the first character to be a digit, on the presumption that
> all TLDs would be alpha-numeric.

> I mention all of this to say that I actually find it 'not clear cut' as to
> what's expected, and have spent several day long dives into specs and
> other implementations to see if there's any common consistency

While I realize that it is not clear cut in many contexts, RFC 5280 is
rather clear cut.  The authors clearly wanted to avoid stumbling and
being eaten by a grue, so they wrote:

   When the subjectAltName extension contains a domain name system
   label, the domain name MUST be stored in the dNSName (an IA5String).
   The name MUST be in the "preferred name syntax", as specified by
   Section 3.5 of [RFC1034] and as modified by Section 2.1 of
   [RFC1123].  Note that while uppercase and lowercase letters are
   allowed in domain names, no significance is attached to the case.  In
   addition, while the string " " is a legal domain name, subjectAltName
   extensions with a dNSName of " " MUST NOT be used.  Finally, the use
   of the DNS representation for Internet mail addresses
   (subscriber.example.com instead of subscri...@example.com) MUST NOT
   be used; such identities are to be encoded as rfc822Name.

This makes it clear that the "preferred name syntax" is not a
recommendation when it comes to certificates.  It is mandatory.

The CA/Browser Forum already has changed the rules for the CAB Forum
X.509 profile to allow dNSName entries to contain "*" which is
contrary to RFC 5280, so maybe the forum should consider other
variations of the rules of 5280.

dev-security-policy mailing list

Reply via email to