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