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
