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" <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/therightkey >> >> >_______________________________________________ >therightkey mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/therightkey _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
