Many Internet protocols require a mapping between some kind of identifier 
and some kind of public 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.