Additional Information

Newsletters

August 2015 Newsletter

August 2015 Newsletter

(posted to certificate-transparency@googlegroups.com, trans@ietf.org and ct-policy@chromium.org)

We wanted to put an update out to summarize what the Certificate Transparency team at Google is working on as well as other efforts in the space that we are aware of. There are lots of other great contributions taking place from other organizations and individuals so we apologize for anything that we’ve missed and we’d also love to hear more about them.

Standards work

Achievements:

Work continues on RFC6962-bis. Version 8 of the draft was published in July [1].

IETF 93 was held in Prague in July, and the following CT presentations took place:

We’re very interested in exploring how we make it viable for a site-owner to be able to opt-in to requiring CT, ahead of any general browser-enforced deadlines. We would welcome participation in helping define what this might look like in a manner that would work well for both browsers and site-owners.

Apple’s new App Transport Security for iOS 9 and Mac OS X 10.11 includes support for Certificate Transparency [1], although we’re not sure exactly what it does yet. Does anyone reading this have details to share?

Chrome 41, released in March of this year, began enforcing the CT requirement for all EV certificates issued after 1 Jan 2015.

Lookahead:

Google is working with the Mozilla Foundation and a contractor to build a patch to contribute to Firefox to provide Certificate Transparency support in Firefox.

Google is planning to launch a set of DNS servers to be able to handle inclusion proof checking over DNS. The primary motivation for doing so is so that a client (such as Chrome, or other browsers that wish to use this) can perform inclusion proof checks without directly revealing the browsing history of the user to any new parties, including Google. The intent is that the client will receive an inclusion proof by performing a DNS lookup for a TXT record for a specially crafted hostname, via the user’s existing DNS resolver (typically an ISP) which in turn will recurse to eventually service the request from a Google DNS server. In this manner the client is only revealing the leaf hashes they see (and thus the sites they visit) to their existing DNS resolver, which already (in practically all cases) has just serviced a DNS request for that same site and thus already knows their browsing history.

Google is building out log mirrors for all logs included by Chrome, and the intent is that read-only requests from Chrome (for STHes, or inclusion-proofs (via the DNS mechanism above)) will be serviced by a log mirror, rather than the underlying logs.

Google is building out Chrome support to include STH fetching, and to use the DNS inclusion proof method outlined above. We intend to provide more information (including protocol details) as we make progress.

Google is working with the OpenSSL community on adding experimental support into OpenSSL client for retrieving and validating all SCTs associated with a TLS connection [2].