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
