On 08/04/16 01:33, Peter Bowen wrote:
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.
That idea may have been discussed, but FWIW I don't see it in any
previous version of the draft.
We did change CN-ID redaction from disallowed to allowed:
https://trac.tools.ietf.org/wg/trans/trac/ticket/17
https://github.com/google/certificate-transparency-rfcs/commit/49de5eb87e1e6d29e50c418c00654a79a950522d
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 notice that "the CN-ID MUST match the first DNS-ID and have the same
labels redacted" is also problematic for IDNs, where some CAs put the
A-label in the SAN dNSName field and the corresponding U-label in the
Subject CN field.
e.g.
https://crt.sh/?id=16244739&opt=cablint
I think we should update the draft to say that the first INTEGER in the
SEQUENCE corresponds to the (zero or more) Subject CN(s), the second
INTEGER corresponds to the first SAN dNSName, etc, etc.
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
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
