A new IETF working group has been formed in the Security Area. For additional information please contact the Area Directors or the WG Chair. Public Notary Transparency (trans) ------------------------------------------------ Current Status: Proposed WG Chairs: Melinda Shore <melinda.shore@gmail.com> Assigned Area Director: Stephen Farrell <stephen.farrell@cs.tcd.ie> Mailing list Address: therightkey@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/therightkey Archive: http://www.ietf.org/mail-archive/web/therightkey/ Charter: Mitigating web site certificate mis-issuance is the initial problem of interest for this working group. Certificate Transparency (CT, RFC6962) allows such mis-issuance to be detected in interesting and useful cases, for example by an auditor acting for the web site, or one acting to check general CA behaviour. The working group will produce a standards-track version of the experimental RFC 6962 for 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 rely on either ad-hoc mappings, (as in a web of trust), or on authorities (such as CAs) that 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 these problems 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. 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 potentially 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. While the privacy issues related to use of RFC6962 for public web sites are minimal, the working group will consider privacy as it might impact on uses of CT e.g. within enterprises or for other uses of logs. Work items: - Publish an update to RFC 6962 as a standards-track mechanism to apply verifiable logs to HTTP over TLS. As DANE (RFC6698) provides an alternative keying infrastructure to that used in the current web PKI, the working group should consider appropriate client behavior in the presence of both DANE-based keying and current web PKI when standardising CT. - Discuss mechanisms and techniques that allow cryptographically verifiable logs to be deployed to improve the security of protocols other 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. Should no such items be chartered the WG will close when documents associated with the first work item are complete. Milestones: TBD
