Thanks for the feedback, I'll change https://github.com/google/certificate-transparency-rfcs/pull/135 accordingly. (More feedback is still welcome, of course, but I also strongly think it is beneficial).
On Wed, Mar 16, 2016 at 1:07 PM, Rob Stradling <[email protected]> wrote: > On 16/03/16 12:22, Eran Messeri wrote: > >> How desirable is it for issuers to be able to embed V1 and V2 SCTs in >> the same certificate? >> > > Eran, thanks for thinking this through. I think that this is definitely > desirable, and I like the solution you've proposed. > > If we don't do this, I think it would adversely affect adoption of V2. > Embedding SCTs in certificates is the only SCT delivery mechanism that all > TLS servers support, and few people are going to want to break > compatibility (by embedding only V2 SCTs in certs) with V1 clients that > still have a significant userbase. > > (Pretend for a moment that "V1" is sha1WithRSAEncryption and "V2" is > sha256WithRSAEncryption. Adoption of sha256WithRSAEncryption for > certificate signatures was extremely slow, because (i) the userbase of > clients that only supported sha1WithRSAEncryption was still significant and > (ii) certificates can only have 1 signature). > > > Background: V1 SCTs (RFC6962) and V2 SCTs (RFC6992-bis) are completely >> different and can co-exist for X.509 certificates as they are delivered >> in different OCSP extensions / TLS exetensions. >> >> In the case of precertificates, while in theory V1 and V2 SCTs can be >> independently embedded (as the X.509 extensions to embed each type are >> different), in practice SCTs for V1 Precertificates cover the entire >> TBSCertificate, including the V2 SCTs (otherwise the V1 SCT won't be >> valid) and the same goes for V2 SCTs. >> >> In RFC6962-bis, as it is defined right now, V1 and V2 SCTs for the same >> precertificate cannot be embedded in the same X.509 certificate. >> It seems to me there would be benefit to enabling this combination, as >> that means issuers can issue certificates that would comply both with V1 >> CT clients and V2 CT clients without forcing V2 clients to also >> implement RFC6962. >> >> The solution I propose: >> - In the normative section of RFC6962-bis about SCT checking, specify >> that TLS clients SHOULD remove the V1 X.509 extension (OID XXX) when >> checking V2 Precertificate SCTs. >> - In an informal appendix, suggest the following process for issuing an >> X.509 certificate that contains valid V1 and V2 SCTs embedded: >> (1) Issuer create a valid RFC6962-bis precertificate and submits it to >> V2 logs, collecting the returned SCTs. >> (2) Issuer embeds the V2 SCTs (as TransItems) into the TBSCertificate >> with the V2 X.509 extension. >> (3) Issuer then adds the poison extension from RFC6962, signs the >> TBSCertificate to produce a valid V1 precertificate, which it then >> submits to V1 logs. >> (4) Issuer embeds the V1 SCTs in the TBSCertificate and signs it, >> producing the final X.509 certificate to be used by the server. >> >> V1 clients would validate the V1 SCTs and ignore the V2 SCTs. >> V2 clients would remove the V1 SCTs and validate the signature over the >> resulting TBSCertificate, which would then exclude V1 and V2 SCTs and be >> identical to the TBSCertificate in the V2 (CMS) precertificate submitted >> to the log. >> >> Thoughts? >> >> Eran >> > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
