[therightkey] Revised Draft Charter for Transparency WG

[Ben Laurie <[e-mail]>]

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[1] can help to ameliorate the
problems by making it possible to discover and rectify errors before
they can cause harm.


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: Specify a standards-track mechanism to apply verifiable
logs to HTTP/TLS (i.e. RFC 6962-bis).


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.


[1] 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, from RFC 6962: “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.”


See RFC 6962, http://www.links.org/files/CertificateTransparencyVersion2.1a.pdf
and http://www.links.org/files/RevocationTransparency.pdf for
background.