Subject: [Trans] 6962-bis: Merging the STH and SCT extension types (issue 173)

From: Eran Messeri <[email-masked]>
Date: Thu, 6 Apr 2017 13:27:57 +0100

I intend to adopt Richard's suggestion of merging the extension types for
SCTs and STHs.

Currently there doesn't seem to be a good reason to separate the two -
since the extensions are typed, it'd be easy to differentiate between the
two, and there may be extensions which are shared between SCTs and STHs.

This has been reviewed in
https://github.com/google/certificate-transparency-rfcs/pull/224, rationale
updated in https://trac.ietf.org/trac/trans/ticket/173.

Eran

---

From: Rob Stradling <[email-masked]>
Date: Thu, 6 Apr 2017 14:12:46 +0100

On 06/04/17 13:27, Eran Messeri wrote:
> I intend to adopt Richard's suggestion of merging the extension types
> for SCTs and STHs.
>
> since the extensions are typed, it'd be easy to differentiate between
> the two, and there may be extensions which are shared between SCTs and STHs.
>
> This has been reviewed
> in https://github.com/google/certificate-transparency-rfcs/pull/224,
> rationale updated in https://trac.ietf.org/trac/trans/ticket/173.

I support this too.

Note: I just did some editorial follow-up work in 
https://github.com/google/certificate-transparency-rfcs/pull/244

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

---

From: Ben Laurie <[email-masked]>
Date: Thu, 6 Apr 2017 14:48:00 +0100

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

Really? I am confused by this plan - surely the extensions for STHs and
SCTs will be different? So what's the value of allowing the wrong ones to
be included?

---

From: Eran Messeri <[email-masked]>
Date: Thu, 6 Apr 2017 14:51:00 +0100

> SCTs will be different? So what's the value of allowing the wrong ones to
We don't know yet, as no extension has been defined - but for each
extension, it must be specified whether it should go in the SCT, STH or
both.
So we'd simply have a single extensions repository, rather than two.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 6 Apr 2017 17:30:27 +0100

OK, but it seems to me you've exchanged two lists for one list with a bunch
of flags. Not sure why this is in any way an improvement?

---

From: Rob Stradling <[email-masked]>
Date: Fri, 7 Apr 2017 14:17:21 +0100

On 06/04/17 17:30, Ben Laurie wrote:
> OK, but it seems to me you've exchanged two lists for one list with a
> bunch of flags. Not sure why this is in any way an improvement?

Do you consider it to be a deprovement?

I think it:
1. simplifies the document a bit.
2. facilitates the writing of one set of code (rather than two sets) to 
support SCT extensions and STH extensions.
3. provides a generic extension mechanism for other sorts of 
transparency log objects to use in the future, should the need arise.

> On 6 April 2017 at 14:51, Eran Messeri wrote:
>
>
>
>     On Thu, Apr 6, 2017 at 2:48 PM, Ben Laurie <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>
>         On 6 April 2017 at 14:12, Rob Stradling
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>                 in
>                 https://github.com/google/certificate-transparency-rfcs/pull/224
>                 <https://github.com/google/certificate-transparency-rfcs/pull/224>,
>                 rationale updated in
>                 https://trac.ietf.org/trac/trans/ticket/173
>                 <https://trac.ietf.org/trac/trans/ticket/173>.
>
>
>             I support this too.
>
>             <https://github.com/google/certificate-transparency-rfcs/pull/244>
>
>
>         Really? I am confused by this plan - surely the extensions for
>         STHs and SCTs will be different? So what's the value of allowing
>         the wrong ones to be included?
>
>     extension, it must be specified whether it should go in the SCT, STH
>     or both.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 7 Apr 2017 09:32:33 -0400

On Fri, Apr 7, 2017 at 9:17 AM, Rob Stradling <[email-masked]>
wrote:

> 3. provides a generic extension mechanism for other sorts of transparency
> log objects to use in the future, should the need arise.
>

Yeah, it's syntactically one thing, so you should only write one encoder /
decoder, and the declared syntax should reflect that.

One reason I think it's an improvement is that it removes the illusion that
the type system will help you distinguish STH and SCT extensions -- with
the current definitions, you can just as well shove an STH extn in an SCT
and vice versa, since they have the same syntax.  If we declare them to
have the same syntax, then it's clear to devs that they need to explicitly
check that the extn types are allowed.

Note that there's prior art here in TLS:

> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 7 Apr 2017 09:32:51 -0400

On Fri, Apr 7, 2017 at 9:32 AM, Richard Barnes <[email-masked]> wrote:

> One reason I think it's an improvement is that it removes the illusion
> that the type system will help you distinguish STH and SCT extensions --
> with the current definitions, you can just as well shove an STH extn in an
> SCT and vice versa, since they have the same syntax.  If we declare them to

Sorry, hit "send" too soon:

https://tlswg.github.io/tls13-spec/#rfc.section.4.2