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

From: Eran Messeri <[email-masked]>
Date: Wed, 3 May 2017 18:53:00 +0100

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?

Eran

---

From: Andrew Ayer <[email-masked]>
Date: Thu, 4 May 2017 08:26:33 -0700

On Wed, 3 May 2017 18:53:00 +0100
Eran Messeri <[email-masked]> wrote:

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

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

---

From: Eran Messeri <[email-masked]>
Date: Thu, 4 May 2017 17:17:37 +0100

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

---

From: Rob Stradling <[email-masked]>
Date: Fri, 5 May 2017 22:48:04 +0100

On 04/05/17 17:17, Eran Messeri wrote:
<snip>
> Rob, who undertook this non-trivial change, may have a more complete

This was the (non-trivial!) change...

https://github.com/google/certificate-transparency-rfcs/pull/89

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online