Re: [9] RFR: 8007706: X.509 cert extension SAN should support "_" in dNSName
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.
Re: [9] RFR: 8007706: X.509 cert extension SAN should support "_" in dNSName
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
Re: [9] RFR: 8007706: X.509 cert extension SAN should support "_" in dNSName
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.
Jason
On 08/04/2014 03:50 AM, Florian Weimer wrote:
On 08/02/2014 04:09 AM, Jason Uh wrote:
Hi Florian,
Thanks for your input. There was some discussion about the issue in the
past on this list:
http://mail.openjdk.java.net/pipermail/security-dev/2013-February/006622.html
Do you disagree with the comments there?
I think the intent of RFC 5280 is *not* to allow "_" in dNSName.
However, other PKIX implementations (OpenSSL, NSS) do not seem to verify
dNSName syntax at all, so it might be necessary to drop the check for
interoperability reasons in OpenJDK, even if it makes OpenJDK less
compliant with RFC 5280.
Re: [9] RFR: 8007706: X.509 cert extension SAN should support "_" in dNSName
On 08/02/2014 04:09 AM, Jason Uh wrote: Hi Florian, Thanks for your input. There was some discussion about the issue in the past on this list: http://mail.openjdk.java.net/pipermail/security-dev/2013-February/006622.html Do you disagree with the comments there? I think the intent of RFC 5280 is *not* to allow "_" in dNSName. However, other PKIX implementations (OpenSSL, NSS) do not seem to verify dNSName syntax at all, so it might be necessary to drop the check for interoperability reasons in OpenJDK, even if it makes OpenJDK less compliant with RFC 5280. -- Florian Weimer / Red Hat Product Security
Re: [9] RFR: 8007706: X.509 cert extension SAN should support "_" in dNSName
On 07/22/2014 09:52 AM, Jason Uh wrote: Hi Max, Could you please review this fix? http://cr.openjdk.java.net/~juh/8007706/webrev.00/ With the fix, the rules will be: 1. A DNSName must begin with a letter or a digit 2. After the first character, valid characters in DNSName components are letters, digits, hyphens, and underscores The underscore bit violates the requirements of RFC 5280. Perhaps the RFC is wrong, but I think more justification is needed. The part which accepts leading digits is fine. Technically, there is a difference between domain names (sequences of dotted case-insensitive label blobs) and host names (labels must consist of letters and digits and hyphens, and start with a letter or digit). RFC 5280 says "domain name", but the references make it clear that "host names" are meant instead. It's not even clear if IA5String can encode backslashes, which would be needed to cover the entire range of valid domain names. -- Florian Weimer / Red Hat Product Security
[9] RFR: 8007706: X.509 cert extension SAN should support "_" in dNSName
Hi Max, Could you please review this fix? http://cr.openjdk.java.net/~juh/8007706/webrev.00/ With the fix, the rules will be: 1. A DNSName must begin with a letter or a digit 2. After the first character, valid characters in DNSName components are letters, digits, hyphens, and underscores A couple minor formatting changes included. Thanks, Jason
