Collected suggestions, in order sent to me: 1. Append-only Transparency Logs (trans) 2. PUblic Notary Transparency (punt) 3. Public Key Transparency (trans) 4. Transparency for public key binding (trans) 5. warnlog 6. canarielog 7. whistle-ledger 8. detection-ledger
My order or preference would be #3, then #2, then #1 and otherwise don't care. If nobody objects (Do you really want to object? Is it important really? :-) I'll let the IESG pick one of those with that suggested ordering. Cheers, S. On 01/14/2014 11:12 PM, Stephen Farrell wrote: > > 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 >>> therightkey@ietf.org >>> https://www.ietf.org/mailman/listinfo/therightkey >>> >>> >> _______________________________________________ >> 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 > > _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
