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

Reply via email to