On Wed, Jul 23, 2014 at 11:11 PM, Stephen Kent <[email protected]> wrote: > Eran, > > 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. > > 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. > Sure, I simply meant this is the current situation (the wording in this section has not changed between RFC6962 and RFC6962-bis).
> > 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. > > I think you mean to say "The only case I see where an intermediate CA > certificate is logged *instead* of an EE certificate ..." right? > > Indeed. > 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? > 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 protected] > https://www.ietf.org/mailman/listinfo/trans > >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
