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

[Stephen Farrell <[e-mail]>]

Thanks Ben,

So folks know what we're thinking and in case all the
process gibberish isn't clear to you all...

Sean and I like the idea of doing this, and the more that
it seems to get broader support, the more we'll like it.

Since there was already a BoF on this back at IETF-85 [1]
that concluded this was work that's relevant to do in
the IETF, we're thinking that if a crisp enough charter
can be crafted on this list then this wouldn't need another
BoF but would be ok to just be pushed into the IESG/IETF
approval process.

What that means is that when Sean and I think we have a
good enough charter draft, then we'll put that into the
datatracker and the IESG will do an IESG-internal review
to decide if its ready to be sent out for IETF review.
If/when the IESG are ok with that going for IETF-wide
review then a mail will go to the IETF discuss list so's
anyone can comment on the proposed new WG. Then the IESG
get to look at it again, and any comments we've gotten,
and approve the new WG or not. Charter text tweaks can
be expected at each stage.

All going well, that could result in a new WG for this
being formed early in the new year, before IETF-89
with the WG having a first f2f meeting there presumably.

So please comment on Ben's text and the above with that
in mind. I assume Ben will hold the pen on draft charter
text and update that as comments are received.

And please use this list for now, since this is the
one we used for RFC 6962 so probably has the right
people. When/if we form a WG we can make a new list
or use this one if folks prefer that.

Thanks,
S.

[1] http://www.ietf.org/proceedings/85/certrans.html

On 12/11/2013 04:55 PM, Ben Laurie wrote:
> Who's in?
> 
> "Problem statement: many Internet protocols require a mapping between
> some kind of identifier and some kind of key, for example, HTTPS,
> SMTPS, IPSec, DNSSEC and OpenPGP.
> 
> These protocols rely on either ad-hoc mappings, or on authorities
> which attest to the mappings.
> 
> 
> History shows that neither of these mechanisms is entirely
> satisfactory. Ad-hoc mappings are difficult to discover and maintain,
> and authorities make mistakes or are subverted.
> 
> 
> Cryptographically verifiable logs can help to ameliorate the problems
> by making it possible to discover and rectify errors before they can
> cause harm.
> 
> 
> These logs can also assist with other interesting problems, such as
> how to assure end users that software they are running is, indeed, the
> software they intend to run.
> 
> 
> 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."
> _______________________________________________
> therightkey mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/therightkey
> 
>