Re: [Trans] v2 SCTs and v1 SCTs distinguishability

[Rob Stradling <[e-mail]>]

>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 [e-mail] 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 <[e-mail]> on behalf of Salz, Rich <rsalz=[e-mail]>
Sent: 12 August 2021 23:15
To: Ryan Sleevi <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
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.


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://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.



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