[9] RFR: 8007706: X.509 cert extension SAN should support "_" in dNSName

[Florian Weimer]

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.

-- 
Florian Weimer / Red Hat Product Security