Subject: [Trans] Co-existence of V1 and V2 embedded SCTs in certificates

From: Eran Messeri <[email-masked]>
Date: Wed, 16 Mar 2016 12:22:50 +0000

How desirable is it for issuers to be able to embed V1 and V2 SCTs in the
same certificate?

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

---

From: Rob Stradling <[email-masked]>
Date: Wed, 16 Mar 2016 13:07:09 +0000

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

> different and can co-exist for X.509 certificates as they are delivered
> in different OCSP extensions / TLS exetensions.
>
> TBSCertificate, including the V2 SCTs (otherwise the V1 SCT won't be
> valid) and the same goes for V2 SCTs.
>
> 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.
> (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.
> 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.
>
> 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

---

From: Eran Messeri <[email-masked]>
Date: Wed, 16 Mar 2016 13:26:25 +0000

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-masked]>
wrote:

> Embedding SCTs in certificates is the only SCT delivery mechanism that all
> TLS servers support, and few people are going to want to break
> clients that only supported sha1WithRSAEncryption was still significant and
> (ii) certificates can only have 1 signature).
>
>

---

From: Eran Messeri <[email-masked]>
Date: Wed, 16 Mar 2016 13:39:57 +0000

On Wed, Mar 16, 2016 at 1:36 PM, "Barreira Iglesias, Iñigo" <
[email-masked]> wrote:

> Agreed, but have in mind that there should be a transition period when RFC
> 6962-bis is published because it affects the issuance procedure in the CA
> and not all are quick enough to implement and the processing in the log
> servers.
>
Understood.
The change mentioned above is about the *ability* to support V1 and V2
simultaneously.
The RFC6962-bis deployment timeline would be, I expect, different for each
TLS client and is out of scope of the bis document itself. But when the
time comes, this change would allow supporting both simultaneously.

>
>
>
>
> *Iñigo Barreira*
> Responsable del Área técnica
> [email-masked]
>
> 945067705
>
>
>
>
>
>
> ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta
> egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea
> gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi
> erantzuna. KONTUZ!
> ATENCION! Este mensaje contiene informacion privilegiada o confidencial a
> la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por
> error le agradeceriamos que no hiciera uso de la informacion y que se
> pusiese en contacto con el remitente.
>
>
>
> *De:* Trans [mailto:[email-masked]] *En nombre de *Eran Messeri
> *Enviado el:* miércoles, 16 de marzo de 2016 14:26
> *Para:* Rob Stradling
> *CC:* [email-masked]
> *Asunto:* Re: [Trans] Co-existence of V1 and V2 embedded SCTs in
> certificates
>
>
>
> (More feedback is still welcome, of course, but I also strongly think it
> is beneficial).
>
>
>

---

From: "Barreira Iglesias, Iñigo" <[email-masked]>
Date: Wed, 16 Mar 2016 14:36:06 +0100

Agreed, but have in mind that there should be a transition period when RFC 6962-bis is published because it affects the issuance procedure in the CA and not all are quick enough to implement and the processing in the log servers.

Iñigo Barreira

945067705

ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.

De: Trans [mailto:[email-masked]] En nombre de Eran Messeri
Enviado el: miércoles, 16 de marzo de 2016 14:26
Para: Rob Stradling
CC: [email-masked]
Asunto: Re: [Trans] Co-existence of V1 and V2 embedded SCTs in certificates

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-masked]> wrote:

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

	
	
	The solution I propose:

	Thoughts?
	
	Eran