Charter for Working Group

Mitigating web site certificate mis-issuance is the initial problem ofinterest for this working group. Certificate Transparency (CT,RFC6962) allows such mis-issuance to be detected in interesting anduseful cases, for example by an auditor acting for the web site, orone acting to check general CA behaviour. The working group willproduce a standards-track version of the experimental RFC 6962for HTTP over TLS, reflecting implementation and deployment experience since that specification was completed.

Many Internet protocols for example, SMTPS, IPsec, DNSSEC, OpenPGP and HTTPS, require a mapping between some kind of identifier and some kind of public key. These protocols relyon either ad-hoc mappings, (as in a web of trust), or on authorities(such as CAs) that attest to the mappings. History shows that neitherof these mechanisms is entirely satisfactory. Ad-hoc mappings aredifficult to discover and maintain, and authorities make mistakes orare subverted.

Cryptographically verifiable logs can help to ameliorate theseproblems by making it possible to discover errors quickly, so that other mechanisms can be applied to rectify them. 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. Forexample, RFC 6962 says: "The append-only property of each log istechnically achieved using Merkle Trees, which can be used to showthat any particular version of the log is a superset of any particularprevious version. Likewise, Merkle Trees avoid the need to blindlytrust logs: if a log attempts to show different things to differentpeople, this can be efficiently detected by comparing tree roots andconsistency proofs. Similarly, other misbehaviors of any log (e.g.,issuing signed timestamps for certificates they then don't log) can beefficiently detected and proved to the world at large."

These logs can potentially also assist with other interestingproblems, such as how to assure end users that software they arerunning is, indeed, the software they intend to run.

While the privacy issues related to use of RFC6962 for publicweb sites are minimal, the working group will consider privacyas it might impact on uses of CT e.g. within enterprises orfor other uses of logs.

Work items:

- Publish an update to RFC 6962 as a standards-track mechanism toapply verifiable logs to HTTP over TLS. As DANE (RFC6698) provides analternative keying infrastructure to that used in the current web PKI,the working group should consider appropriate client behavior in thepresence of both DANE-based keying and current web PKI whenstandardising CT.

- Discuss mechanisms and techniques that allow cryptographicallyverifiable logs to be deployed to improve the security of protocolsother than HTTP over TLS, for example SMTP/TLS or software distribution. Where such mechanisms appear sufficiently useful, the WG will re-charter to add relevant new work items. Shouldno such items be chartered the WG will close when documents associated with the first work item are complete.