Re: [Trans] Ticket 179 - moving Cert/Precert indicator into the data structure

[Eran Messeri <[e-mail]>]

On Thu, May 4, 2017 at 4:26 PM, Andrew Ayer <[e-mail]> wrote:

> On Wed, 3 May 2017 18:53:00 +0100
> Eran Messeri <[e-mail]> wrote:
>
> > I'm looking for opinions on ticket 179
> > <https://trac.ietf.org/trac/trans/ticket/179>, which suggests
> > "folding" the Cert/Precert indicator for an SCT into the data
> > structure contained in the TransItem (right now it's part of the
> > TransItem type indicator).
> >
> > Personally I find it hard to justify such a change, since SCTs are
> > already clearly defined as TransItems and it's a non-trivial change
> > to the data structures without a strong benefit.
> >
> > Suggestions?
>
> I agree that there isn't a very strong justification for making a
> non-trivial change like this.
>
> I would also like to understand why 6962-bis consolidated all the type
> indicators into a single one before that work is undone.
>
In 6962 different structures had versions (SCT, MerkleTreeLeaf,
TreeHeadSignature), making it appear as if "v2" STHs can be mixed with "v1"
SCTs or tree leaves.
In practice, while it may be possible, it's not as straightforward as the
independent data structure versioning makes it appear, since there's a
dependency between the data structures.

Moving the version to the topmost layer, together with the data structure
type, makes it explicit which type is being dealt with.
Another problem is that the different versions in 6962 were incorrectly
interpreted by implementations, some using a "global" versioning scheme,
some using per-type versioning scheme, and not all implementations checking
these are versions they know about.

Requiring inspection of the (versioned) type for correct interpretation of
the TransItem forces implementations to consider the version they're
dealing with, removing the potential pitfall
of having a version field that's not properly checked.

Rob, who undertook this non-trivial change, may have a more complete
context.

>
> Absent a stronger justification and an explanation of why the
> consolidation was done in the first place, I favor keeping 6962-bis
> as-is.
>
> Regards,
> Andrew
>