Opened 6 years ago

Closed 6 years ago

Last modified 11 months ago

#157 closed enhancement (fixed)

Conflate Version and TransType

Reported by: rob.stradling@… Owned by: rob.stradling@…
Priority: major Milestone: review
Component: rfc6962-bis Version:
Severity: - Keywords:


With TransItem? support for v1 (RFC6962) disappearing in ticket #153, it seems that having the type and version as separate fields just seems to complicate matters unnecessarily. So let's conflate the two fields:

enum {

(0), x509_entry_v2(1), precert_entry_v2(2), x509_sct_v2(3),
precert_sct_v2(4), tree_head_v2(5), signed_tree_head_v2(6),
consistency_proof_v2(7), inclusion_proof_v2(8), (65535)

} TransTypeAndVersion?;

The zero value is reserved to avoid confusion with a v1 SCT (which is guaranteed to have zero as its first byte).

Change History (5)

comment:1 Changed 6 years ago by eranm@…

Sounds good to me - not only will it remove a field, it will also make it crystal clear in implementations which SCTs and other data structures the code is referring to (assuming they stick to the RFC naming convention!).

The only suggestion I have, and it's a very minor one, is to name it VersionedTransType?.

comment:2 Changed 6 years ago by rob.stradling@…

  • Owner changed from draft-ietf-trans-rfc6962-bis@… to rob.stradling@…
  • Status changed from new to assigned


comment:4 Changed 6 years ago by melinda.shore@…

  • Resolution set to fixed
  • Status changed from assigned to closed

comment:5 Changed 11 months ago by trains@…

Since draft-ietf-trans-rfc6962-bis-22, the draft said

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

However, Section 1.2 says

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

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.

v1 SCTs from RFC6962 used the first byte, set to zero, for the Version field. v2 uses a big-endian two-byte number. For a TransItem structure to be consistently distinguishable from a v1 SCT, the first byte has to be nonzero, so all of the VersionedTransType values from 0x0000 to 0x00ff would have to be reserved, 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.)

Note: See TracTickets for help on using tickets.