Re: [Trans] v2 SCTs and v1 SCTs distinguishability

[Ryan Sleevi <[e-mail]>]

On Thu, Aug 12, 2021 at 4:22 PM Salz, Rich <rsalz=
[e-mail]> wrote:

> I think you are confusing the bytes on-the-network compared.
>
> >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.
>
> In the network representation, yes, but not when it's in internal/native
> format.
>

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?