Subject: [Trans] Issue with redaction and CN-IDs

From: Rick Andrews <[email-masked]>
Date: Thu, 7 Apr 2016 16:32:36 -0700

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.

-Rick

---

From: Peter Bowen <[email-masked]>
Date: Thu, 7 Apr 2016 17:33:43 -0700

> 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

---

From: Rick Andrews <[email-masked]>
Date: Thu, 7 Apr 2016 17:46:19 -0700

-----Original Message-----
From: Peter Bowen [mailto:[email-masked]]
Sent: Thursday, April 07, 2016 5:34 PM
To: Rick Andrews <[email-masked]>
Cc: [email-masked]
Subject: Re: [Trans] Issue with redaction and CN-IDs

<snip>

	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.

Dan Kaminsky's PKI Layer Cake paper 
(https://www.cosic.esat.kuleuven.be/publications/article-1432.pdf) exposed 
vulnerabilities around multiple CN-IDs, but we neglected to outlaw them in the 
CABF BRs.

-Rick

---

From: Peter Bowen <[email-masked]>
Date: Thu, 7 Apr 2016 17:47:40 -0700

> vulnerabilities around multiple CN-IDs, but we neglected to outlaw them in the

Ah, then ignore that question in the trans context.  We can fix in the
CABF context.

---

From: Rob Stradling <[email-masked]>
Date: Fri, 8 Apr 2016 10:58:54 +0100

The CABForum BRs say this:

"7.1.4.2.2. Subject Distinguished Name Fields
a. Certificate Field: subject:commonName (OID 2.5.4.3)
Required/Optional: Deprecated (Discouraged, but not prohibited)
Contents: If present, this field MUST contain a single IP address or 
Fully‐Qualified Domain Name that is one of the values contained in the 
Certificate's subjectAltName extension (see section 7.1.4.2.1)."

I believe the intent of "...MUST contain a single...that is one of the 
values..." was to outlaw multiple CN-IDs.  Clarification would help though.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Rob Stradling <[email-masked]>
Date: Fri, 8 Apr 2016 11:32:02 +0100

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

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

---

From: Stephen Kent <[email-masked]>
Date: Fri, 8 Apr 2016 09:25:23 -0400

Peter,

It's good that this potential problem has been identified, but it
ought to be addressed in 6962-bis, not via an action in the CABF context.
I say this for a few reasons:

     - CABF cert policies do not apply to all cert that one might encounter
       in a browser
     - Eran has argued that CT applies to all TLS-based communications, not
       just browser/web server interactions (I still disagree about this)
     - 6962-bis wants to become an IETF standard and thus relying on an 
external
       spec to address a potential security concern is not appropriate.

If Rob can adjust text in 6962-bis to address this problem, that's the 
preferred approach.

Steve

> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 8 Apr 2016 13:38:51 +0000

> If Rob can adjust text in 6962-bis to address this problem, that's the

Plus-one!

---

From: Peter Bowen <[email-masked]>
Date: Fri, 8 Apr 2016 07:15:58 -0700

> If Rob can adjust text in 6962-bis to address this problem, that's the

Stephen,

This is obviously the correct answer.

The real challenge will be determining how to map redaction info to
the DN, given that DN is a SEQUENCE OF(SET OF(Attribute)) and that SET
is unordered.  I'm thinking the right answer is to borrow ASN.1
Distinguished Encoding Rules to set the order of SET when a SET has
more than one commonName attribute, as I think the most common state.

Thanks,
Peter

---

From: Rob Stradling <[email-masked]>
Date: Fri, 8 Apr 2016 22:40:02 +0100

On 08/04/16 15:15, Peter Bowen wrote:
> is unordered.

We originally said that CNs could not be redacted at all because we were 
trying to avoid this complexity.

> I'm thinking the right answer is to borrow ASN.1

Does anyone actually need the ability to redact different numbers of 
labels in multiple CNs?

I'm guessing not, in which case let's not make this more complex than it 
needs to be.

---

From: Peter Bowen <[email-masked]>
Date: Fri, 8 Apr 2016 15:08:38 -0700

On Fri, Apr 8, 2016 at 2:40 PM, Rob Stradling <[email-masked]> wrote:
> Does anyone actually need the ability to redact different numbers of labels
> in multiple CNs?
>

So I think the easiest method would be to append one more element to
the sequence for CN redaction level.  I think it should go at the end,
rather than the beginning, as it should be more likely to not have a
common name than not having a SAN.