Subject: [Trans] When are non-EE certificates expected to be logged?

From: Eran Messeri <[email-masked]>
Date: Wed, 23 Jul 2014 21:30:15 +0100

Following a discussion about correlating SCTs to certificates (ticket 23
<http://trac.tools.ietf.org/wg/trans/trac/ticket/23>):

My understanding is that any intermediate CA certificate may be logged
(either as a Precertificate or after issuance) *in addition* to the
end-entity certificate.

RFC6962 only requires TLS clients to validate SCTs for server certificates
(presumably end-entity certificates), so SCTs for any intermediate is not
very useful.

The only case I see where an intermediate CA certificate is logged
*instead* of a CA certificate is when a Name-Constrained intermediate CA
cert is logged.

In light of this, it seems that ticket 23 can be solved by specifying that
TLS clients check all non-embedded SCTs against the end-entity certificate
or the intermediate certificate with extension OID 1.3.6.1.4.1.11129.2.4.7.

Eran

---

From: Stephen Kent <[email-masked]>
Date: Wed, 23 Jul 2014 18:11:22 -0400

Eran,
> Following a discussion about correlating SCTs to certificates (ticket 
> 23 <http://trac.tools.ietf.org/wg/trans/trac/ticket/23>):
>
> RFC6962 only requires TLS clients to validate SCTs for server 
> certificates (presumably end-entity certificates), so SCTs for any 
> intermediate is not very useful.
6962 is experimental, so it's not binding. It's what this new doc says, 
when approved by the WG
and the IESG, that counts.
> *instead* of a CA certificate is when a Name-Constrained intermediate 
> CA cert is logged.
I think you mean to say "The only case I see where an intermediate CA 
certificate is logged *instead* of an EE certificate ..." right?
> In light of this, it seems that ticket 23 can be solved by specifying 
> that TLS clients check all non-embedded SCTs against the end-entity 
> certificate or the intermediate certificate with extension OID 
> 1.3.6.1.4.1.11129.2.4.7.
This statement isn't as clear as it needs to be, since it talks about 
what a client does for a
non-embedded SCT. Does a TLS client check an SCT that it encounters 
embedded in a CA cert?

Steve

---

From: Eran Messeri <[email-masked]>
Date: Thu, 24 Jul 2014 00:30:33 +0100

> and the IESG, that counts.
Sure, I simply meant this is the current situation (the wording in this
section has not changed between RFC6962 and RFC6962-bis).

> Indeed.

> This statement isn't as clear as it needs to be, since it talks about what
> a client does for a
That's the point - the current wording of RFC6962-bis says nothing about
the client should be doing regarding SCTs embedded in non-EE certificates.
My proposal is to say TLS clients SHOULD check SCTs against the EE
certificate OR the intermediate with said extension OID.

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

---

From: Rob Stradling <[email-masked]>
Date: Mon, 28 Jul 2014 21:58:18 +0100

On 24/07/14 00:30, Eran Messeri wrote:
> On Wed, Jul 23, 2014 at 11:11 PM, Stephen Kent wrote:
<snip>
>>     In light of this, it seems that ticket 23 can be solved by
>>     specifying that TLS clients check all non-embedded SCTs against
>>     the end-entity certificate or the intermediate certificate with
>>     extension OID 1.3.6.1.4.1.11129.2.4.7.
>     This statement isn't as clear as it needs to be, since it talks
>     about what a client does for a
> the client should be doing regarding SCTs embedded in non-EE
> certificates. My proposal is to say TLS clients SHOULD check SCTs
> against the EE certificate OR the intermediate with said extension OID.

There could be multiple intermediate certs containing said extension OID 
in the chain up to the root cert.  There could even be multiple 
certificate chains from the EE cert to 1 or more root certs, and more 
than one of those chains could contain intermediate cert(s) with said 
extension OID!

What do you think about my alternative idea (see the comments on ticket 23)?

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

---

From: Eran Messeri <[email-masked]>
Date: Wed, 30 Jul 2014 16:47:46 +0100

On Mon, Jul 28, 2014 at 9:58 PM, Rob Stradling <[email-masked]>
wrote:

> in the chain up to the root cert.  There could even be multiple certificate
> chains from the EE cert to 1 or more root certs, and more than one of those
> chains could contain intermediate cert(s) with said extension OID!
>

Given the cases you've mentioned above, I think it'd make sense to use the
metadata addition to the data structure you proposed.
I'll merge ticket 23 with ticket 10.

---

From: Rob Stradling <[email-masked]>
Date: Wed, 30 Jul 2014 16:53:36 +0100

On 30/07/14 16:47, Eran Messeri wrote:
<snip>
> Given the cases you've mentioned above, I think it'd make sense to use
> the metadata addition to the data structure you proposed.

Thanks Eran.