Re: [therightkey] Draft charter for a Transparency Working Group

[Ben Laurie <[e-mail]>]

On 12 December 2013 12:26, Stephen Farrell <[e-mail]> wrote:
>
> Hi Ben,
>
> I've a question.
>
> On 12/11/2013 04:55 PM, Ben Laurie wrote:
>> Work items: Specify a standards-track mechanism to apply verifiable
>> logs to HTTP/TLS (i.e. RFC 6962-bis).
>>
>> Discuss mechanisms and techniques that allow cryptographically
>> verifiable logs to be deployed to improve the security of protocols
>> and software distribution. Where such mechanisms appear sufficiently
>> useful, the WG will re-charter to add relevant new work items."
>
> I'd like to get a feel for how these work items
> might be sequenced.
>
> For the 2nd one, I assume the modus-operandi would
> be for folks interested in transparency-for-X to
> write up a personal draft, have that discussed on
> the WG list and for stuff for which the WG achieve
> consensus to re-charter to add new work items to
> tackle transparency-for-X to the charter. That
> seems fine to me. (And people can starting writing
> those today - the more that exists before the WG
> would be chartered, the easier it'll all be.)
>
> For the first one, I'm not clear as to whether
> you intend to 1) first consider a set of
> transparency-for-X proposals, re-charter and
> to only then figure out how to re-factor 6962
> into a set of standards-track RFCs, or
>
> 2) if you want to do the work of generating a
> standards-track set of RFCs based on 6962 for
> HTTP/TLS before the WG have considered a set
> of transparency-for-X proposals.
>
> Or maybe 3) you wanted that to emerge from
> this chartering discussion.
>
> Can you clarify? If (1) or (2) apply then it'd
> probably be useful to include that explicitly
> in the charter text. If (3) applies then I guess
> you'd want to actively lead the discussion down
> that path, which sort of seems to be happening
> already.

None of the above?

I want to generate standards-track RFC(s) for 6962-bis, but other
stuff could proceed in parallel. I don't want to hold up 6962-bis for
that other stuff, though.

> And note I'm not asking here about the specific
> set of RFCs as deliverables nor the timing of
> those deliverables, just how the ordering of
> HTTP/TLS vs. other stuff would happen at a
> coarse-grained level. (Separately, it'd be good
> to chat about what RFC deliverables are likely
> to be wanted, but probably only after the
> above is clear.)
>
> Thanks,
> S.