On Thu, Apr 7, 2016 at 4:32 PM, Rick Andrews <[email protected]> wrote: > Section 4.2 in 6962-bis says: > When a precertificate contains that extension and contains a CN-ID > [RFC6125], the CN-ID MUST match the first DNS-ID and have the same > labels redacted. TLS clients will use the first entry in the > SEQUENCE OF INTEGERs to reconstruct both the first DNS-ID and the CN- > ID. > > I'm aware of a problem (confirmed by Peter Bowen at Amazon) with Java7 and > Java8 where getting a new certificate with a different SAN ordering from the > previous one will prevent those Java clients from successfully validating > the new certificate, at least until the cache in the client expires the old > cert information. In most cases, we put the CN-ID in the first SAN field, > but there are exceptions made in cases like this. > > I think the spec used to say that the first item in the SEQUENCE represented > the CN-ID, and I missed the discussion where that changed.
More than just working around bugs in Java, there are names that can be placed in a dNSName entry that cannot be commonName value due to length. According to RFC5280, commonName has an upper bound of 64 total characters while dNSNames have a bound of 63 characters per label and a total length limit in excess of 200 characters. Therefore a CA may not be able to place the first DNS-ID in the CN-ID field. I also wonder how to handle multiple CN-IDs in a single certificate. There is not, to my knowledge, a requirement that the Subject only contain one attribute of type commonName. Thanks, Peter _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
