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.)
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
