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