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

I totally understand the problem statement. But what concrete things can
you enumerate as goals/output of the WG?

Jason

On 12/11/13, 12:23 PM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote:

>
>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
>> therightkey@ietf.org
>> https://www.ietf.org/mailman/listinfo/therightkey
>> 
>> 
>_______________________________________________
>therightkey mailing list
>therightkey@ietf.org
>https://www.ietf.org/mailman/listinfo/therightkey