Re: [therightkey] Revised Draft Charter for Transparency WG

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
> 
> 