On Fri, Apr 7, 2017 at 9:32 AM, Richard Barnes <[email protected]> wrote: > > > On Fri, Apr 7, 2017 at 9:17 AM, Rob Stradling <[email protected]> > wrote: > >> 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. >> > > 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: >
Sorry, hit "send" too soon: https://tlswg.github.io/tls13-spec/#rfc.section.4.2 > > > > >> >> On 6 April 2017 at 14:51, Eran Messeri wrote: >>> >>> >>> >>> On Thu, Apr 6, 2017 at 2:48 PM, Ben Laurie <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>> On 6 April 2017 at 14:12, Rob Stradling >>> <[email protected] <mailto:[email protected]>> >>> wrote: >>> >>> 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. >>> >>> 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/cert >>> ificate-transparency-rfcs/pull/224 >>> <https://github.com/google/cer >>> tificate-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. >>> >>> Note: I just did some editorial follow-up work in >>> https://github.com/google/certificate-transparency-rfcs/pull >>> /244 >>> <https://github.com/google/certificate-transparency-rfcs/pul >>> l/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? >>> >>> 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. >>> >> >> -- >> Rob Stradling >> Senior Research & Development Scientist >> COMODO - Creating Trust Online >> >> _______________________________________________ >> Trans mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/trans >> > >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
