Thanks Ben, Paul. I've kicked off the chartering process. [1]
All going smoothly (which it doesn't always;-) this could be a WG at IETF-89. I've put in a placeholder BoF request so a slot is assigned for that when we schedule the meeting. (That's [2] which you can ignore unless someone asks why its there.) Cheers, S. [1] https://datatracker.ietf.org/doc/charter-ietf-trans/ [2] https://trac.tools.ietf.org/bof/trac/wiki/WikiStart#Security On 01/07/2014 04:35 PM, Paul Hoffman wrote: > I support the formation of this WG with basically this charter. However, > having footnote in a charter make it harder to read. Having URLs that are not > somewhat guaranteed to be available forever (such as those run by the IETF) > make the charter unstable. A proposed editorial-only cleanup: > > 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. A > cryptographically verifiable > log is an append-only log of hashes of more-or-less anything that is > structured in such a > way as to provide efficiently-accessible, cryptographically-supported > evidence of correct > log behaviour. For example, RFC 6962 says: "The append-only property of each > log is > technically achieved using Merkle Trees, which can be used to show that any > particular > version of the log is a superset of any particular previous version. > Likewise, Merkle Trees > avoid the need to blindly trust logs: if a log attempts to show different > things to > different people, this can be efficiently detected by comparing tree roots > and consistency > proofs. Similarly, other misbehaviors of any log (e.g., issuing signed > timestamps for > certificates they then don't log) can be efficiently detected and proved to > the world at > large." > > 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: > > - Publish an update to RFC 6962 as a standards-track mechanism to apply > verifiable logs to > HTTP over TLS. > > - 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
