First and predictable comment: "Transparency WG" is too generic.
Best crappy suggestion I have is "Append-only Transparency Logs" but to keep the trans abbreviation. Better suggestions welcome. (Again offlist is fine since its mostly bikeshedding about which we only care just enough to irritate ourselves;-) S. On 01/14/2014 06:02 PM, Stephen Farrell wrote: > > 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 > > _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
