Summary

This is an identical CSR to that in JDK 12 : JDK-8214270

This is request for 11.0.3 update. Given that our JDK 11 spec already mentioned RFC 5280 in the X509CertSelector API, I don't see an issue with correcting our JDK 11 implementation. RFC 5280 itself makes reference to the more liberal DNS naming format in RFC 1123 § 2.1.

The JDK 12 CSR (and below) do make reference to the DNSName javadoc (specification) but given that it's a private, implementation class in sun.security.x509 package, I don't think there's any harm in updating the code comments.

==== Beginning of JDK 12 CSR paste: ====

The java.security.cert.X509CertSelector.addSubjectAlternativeName(..) methods and the JDK keytool binary utility currently follow RFC 1034 guidelines when creating DNSName attributes. RFC 1123 relaxed those guidelines to allow DNSNames to begin with a digit. The same relaxation should be made in the JDK libraries.

Problem

The sun.security.x509.DNSName JDK specific implementation class is used by the JDK to construct dns specific names which may be used in X509Certificate fields. Currently, its constructor doesn't allow such fields to begin with a digit. This was most likely adopted from the RFC 1034 naming convention. This causes interoperability issues with other tooling systems which allow such names to begin with a digit.

RFC 1123 § 2.1 permits a DNSName to begin with a digit.

https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/security/cert/X509CertSelector.html#addSubjectAlternativeName(int,java.lang.String) makes reference to RFC 5280 § 4.2.1.6 regards the format of the String used. The RFC section contains the following specification :

 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].

https://tools.ietf.org/html/rfc1034#section-3.5 https://tools.ietf.org/html/rfc1123#section-2.1

Solution

Relax the sun.security.x509.DNSName constructor and allow DNSNames (hostnames) to begin with a digit as per RFC 1123 § 2.1 This will allow the JDK utility to inter-operate better with other X.509 type tool stacks.

https://tools.ietf.org/html/rfc1123#section-2.1

Specification

java.security.cert.X509CertSelector will have a behavioural change to allow X509 DNSName extentions to contain names that begin with an alpha-numerical character.

The JDK keytool utility behaviour will also change for constructor of X509 Certificates which contain DNSName fields. The tool will no longer throw a java.io.IOException: DNSName components must begin with a letter issue if a DNSName which starts with a digit is passed as a parameter, e.g. -ext san=dns:1abc.com would be accepted.

The RFC 2459 reference extracts in the sun.security.x509.DNSName code will be substituted with the RFC 5280 successor. More importantly, the relevant specification text will also be updated :

- * The name MUST be in the "preferred name syntax," as specified by RFC
- * 1034 [RFC 1034]. Note that while upper and lower case letters are
- * allowed in domain names, no signifigance is attached to the case.  In
+ * 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.