Thanks, Florian. I will withdraw my review request and close this issue.
I'll file a separate bug to allow the first character to be a digit, as
RFC 1123 relaxed that restriction.
Thanks,
Jason
On 08/04/2014 11:58 PM, Florian Weimer wrote:
On 08/05/2014 07:52 AM, Jason Uh wrote:
Hi Florian,
I've reviewed the RFC again and think there might be some
misinterpretation. The only part I see about underscores reads:
Implementers should note that the at sign ('@') and underscore ('_')
characters are not supported by the ASN.1 type PrintableString.
These characters often appear in Internet addresses. Such addresses
MUST be encoded using an ASN.1 type that supports them. They are
usually encoded as IA5String in either the emailAddress attribute
within a distinguished name or the rfc822Name field of GeneralName.
Conforming implementations MUST NOT encode strings that include
either the at sign or underscore character as PrintableString.
RFC 5280 doesn't allow underscores for *PrintableString*, but DNSName is
an *IA5String*, which does support them.
By this argument, the patch is still not correct because it leaves in
additional checking incompatible with IA5String. (It is also not clear
to me what exactly is permissible in IA5Strings and how codepoints are
supposedly mapped to their Unicode counterparts if a national variant of
T.50 is used, but that's a different issue.) Relaxing all restrictions
would match what other software does.
My claim that '_' is not allowed in dNSName is based on these two
sentences:
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].
Section 3.5 of RFC 1034 and section 2.1 of RFC 1123 deal with host name
syntax, and the grammar in RFC 1034 (and RFC 952, which is referenced in
RFC 1123) does not permit underscores.
