Subject: [Trans] v2 SCTs and v1 SCTs distinguishability

From: [email-masked]
Date: Wed, 11 Aug 2021 20:30:30 +0000

https://trac.ietf.org/trac/trans/ticket/157

draft-ietf-trans-rfc6962-bis says

>  *  The 0x0000 value is reserved so that v1 SCTs are distinguishable
>     from v2 SCTs and other "TransItem" structures.

but Section 1.2 says

>  Data structures are defined and encoded according to the conventions
>  laid out in Section 3 of [RFC8446].

and RFC8446 says

>  All values, here and elsewhere in the specification, are transmitted
>  in network byte (big-endian) order; the uint32 represented by the hex
>  bytes 01 02 03 04 is equivalent to the decimal value 16909060.

So v1 SCTs and v2 structures both still have zero as the first byte, 
unless you change v2 to reserve the range 0x0000 to 0x00FF, not just 
0x0000.

(As is, new v2 SCTs might be mistaken for v1 SCTs, but also in the other 
direction, the 2nd byte in a v1 SCT is the start of the hash of the 
log's public key, so there's a small chance a particular log could 
produce v1 SCTs that resemble v2 because that 1st byte of its SPKI hash 
happens to equal 3 or 4.)

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 12 Aug 2021 20:21:52 +0000

I think you are confusing the bytes on-the-network compared.

In the network representation, yes, but not when it's in internal/native format.

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 12 Aug 2021 16:55:42 -0400

> In the network representation, yes, but not when it's in internal/native

I'm not sure I understand this remark, Rich, but it may be PEBKAC on my
part.

The issue being discussed, if I understand correctly is perhaps best
demonstrated through
https://github.com/google/certificate-transparency-rfcs/commit/ddaff4fc87cb52bbcb84891abec6cdac371d2935

Namely, early on, we distinguished an RFC 6962 SignedCertificateTimestamp (
https://datatracker.ietf.org/doc/html/rfc6962#section-3.2 ) from a 6962-bis
TransItemV2 through the use of the "placeholder" struct - TransItem. The
only overlap a TransItem and a SignedCertificateTimestamp have is the
'version' field, which is a u8 field - 0..255.

6962-bis originally specified a new version v2(1), which indicated the
presence of the completely different fields in a TransItem from those of a
v1(0) SignedCertificateTimestamp.

Following version in 6962's SignedCertificateTimestamp is a LogID (a 32
byte array), while in 6962-bis was the field TransType, a u8 field.

With
https://github.com/google/certificate-transparency-rfcs/commit/919489291b7c9556d70e91e830045d54f7441f1f
, TransType and Version were folded into a u16 field. As a consequence, the
first byte in a 6962 SCT (the "version") no longer distinguishes a 6962-bis
TransItem (the "VersionedTransType"), because a v1 client attempting to
read a byte sequence will read a 0x00 from the network (indicating a v1
SCT), even if the actual enum value is 0x0001

That said, I'm struggling to think that this actually matters, due to the
fact that the TransItem is no longer presented the same as the
SignedCertificateTimestamp - that is, as discussed in
https://www.ietf.org/archive/id/draft-ietf-trans-rfc6962-bis-41.html#name-presenting-scts-inclusions-
, these are conveyed through separate TLS extension (transparency_info), as
well as new X.509 and OCSP extensions (
https://www.ietf.org/archive/id/draft-ietf-trans-rfc6962-bis-41.html#name-transparency-information-x5
), so this overlap in "how to interpret first byte" is no longer relevant.

Is that what you were trying to convey? Did I bodge something?

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 12 Aug 2021 22:15:35 +0000

No, I misread the concern so the PEBKAC is on me.

>That said, I'm struggling to think that this actually matters, due to the fact that the TransItem is no longer presented the same as the SignedCertificateTimestamp - that is, as discussed in https://www.ietf.org/archive/id/draft-ietf-trans-rfc6962-bis-41.html#name-presenting-scts-inclusions-<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-trans-rfc6962-bis-41.html*name-presenting-scts-inclusions-__;Iw!!GjvTz_vk!FdBQc1XlZqkUsWHiXq4_ISAgESX6182gBKlZddj8AIyx11QBuw1PKfBCSGZB$> , these are conveyed through separate TLS extension (transparency_info), as well as new X.509 and OCSP extensions ( https://www.ietf.org/archive/id/draft-ietf-trans-rfc6962-bis-41.html#name-transparency-information-x5<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-trans-rfc6962-bis-41.html*name-transparency-information-x5__;Iw!!GjvTz_vk!FdBQc1XlZqkUsWHiXq4_ISAgESX6182gBKlZddj8AIyx11QBuw1PKZ9wEdMH$> ), so this overlap in "how to interpret first byte" is no longer relevant.

That makes sense to me.  Perhaps the original poster is fetching SCT’s some other way and there’s no context to distinguish them?

---

From: Rob Stradling <[email-masked]>
Date: Mon, 16 Aug 2021 11:41:54 +0000

>From memory our (the authors) concern was that a log client that supports both CTv1 and CTv2 might create a "bag of SCTs" or even a "bag of TransItems", obtained from various sources, but not retain metadata about which source supplied which one.  It therefore seemed intuitive that each SCT and each TransItem should self-describe its type and version without any ambiguity, which meant that we needed to ensure that CTv2 TransItems cannot have a 0x00 byte in the position where a CTv1 SCT parser looks for the SCT Version byte.

However, this current thread correctly points out that we screwed up.  The error is obvious in the Description of https://trac.ietf.org/trac/trans/ticket/157, so...err...sorry about that.

Perhaps (as Ryan pondered) this version ambiguity might never become a problem in practice, but I know that my foresight doesn't stretch far enough into the future to be confident of that.  In any case, we need to fix the document somehow, because it shouldn't claim to deliver, but fail to deliver, SCT version un-ambiguity.

I think we should go with the proposal from [email-masked] to "reserve the range 0x0000 to 0x00FF, not just 0x0000" and renumber the initial entries in the VersionedTransType registry accordingly.  We haven't yet gone through AUTH48, so I'm hoping there's still time to get consensus from the Chairs, A-D, IANA, and the RFC Editor to approve this change.

I've proposed a PR: https://github.com/google/certificate-transparency-rfcs/pull/346

Given the (presumed) lack of any 6962-bis implementations thus far, I'm hoping that this PR wouldn't negatively affect anyone.

________________________________
From: Trans <[email-masked]> on behalf of Salz, Rich <rsalz=[email-masked]>
Sent: 12 August 2021 23:15
To: Ryan Sleevi <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Trans] v2 SCTs and v1 SCTs distinguishability

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

>That said, I'm struggling to think that this actually matters, due to the fact that the TransItem is no longer presented the same as the SignedCertificateTimestamp - that is, as discussed in https://www.ietf.org/archive/id/draft-ietf-trans-rfc6962-bis-41.html#name-presenting-scts-inclusions-<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-trans-rfc6962-bis-41.html*name-presenting-scts-inclusions-__%3BIw!!GjvTz_vk!FdBQc1XlZqkUsWHiXq4_ISAgESX6182gBKlZddj8AIyx11QBuw1PKfBCSGZB%24&data=04%7C01%7Crob%40sectigo.com%7Cc7927d04f06640db279e08d95ddec97b%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637644033733001818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=n%2BAT09XdWHlfARfhmr6Sjqoy7pRHTFKiglZm4YM88Cc%3D&reserved=0> , these are conveyed through separate TLS extension (transparency_info), as well as new X.509 and OCSP extensions ( https://www.ietf.org/archive/id/draft-ietf-trans-rfc6962-bis-41.html#name-transparency-information-x5<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-trans-rfc6962-bis-41.html*name-transparency-information-x5__%3BIw!!GjvTz_vk!FdBQc1XlZqkUsWHiXq4_ISAgESX6182gBKlZddj8AIyx11QBuw1PKZ9wEdMH%24&data=04%7C01%7Crob%40sectigo.com%7Cc7927d04f06640db279e08d95ddec97b%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637644033733011774%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AV%2Bm97TXvAOZryyiL0b2d5DWr294B9lJvm3ZV3fBpRE%3D&reserved=0> ), so this overlap in "how to interpret first byte" is no longer relevant.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 16 Aug 2021 14:05:57 +0000

>I've proposed a PR: https://github.com/google/certificate-transparency-rfcs/pull/346<https://urldefense.com/v3/__https:/github.com/google/certificate-transparency-rfcs/pull/346__;!!GjvTz_vk!CoZVonAFXdQTAWJ12FXDisaJfKxUau6GEkvdJJ5qPqbh8ryyNl-X98uxLyWt$>

I’m still not convinced this is necessary, but there is no harm in keeping them far apart.  I’m fine with this.

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 16 Aug 2021 13:46:31 -0400

On Mon, Aug 16, 2021 at 10:06 AM Salz, Rich <[email-masked]> wrote:

> >I've proposed a PR:
> https://github.com/google/certificate-transparency-rfcs/pull/346
> <https://urldefense.com/v3/__https:/github.com/google/certificate-transparency-rfcs/pull/346__;!!GjvTz_vk!CoZVonAFXdQTAWJ12FXDisaJfKxUau6GEkvdJJ5qPqbh8ryyNl-X98uxLyWt$>
>
>
>

Same