[Cryptography] Certificate transparency on blockchains

[Paul Wouters]

On Wed, 25 Mar 2015, Greg wrote:

> Wherein Google's CT is compared with blockchains against the goals that Google set for CT.
> 
> Also, a mechanism for keeping DNSChain servers honest is presented at the end.
> 
> https://blog.okturtles.com/2015/03/certificate-transparency-on-blockchains/

Note: I am the IETF co-chair of the trans working group responsible for CT. You can read
up on the drafts at: https://datatracker.ietf.org/wg/trans/documents/

By calling it "Google CT", it purposefully ignores the fact that this
is an IETF standard: RFC 6962.

 	CA/log combos can use hidden Merkle trees to hide certificate
 	issuance, even in a world where CT is mandatory for all CAs. The CT spec
 	allows only one SCT to accompany a certificate, making  this attack
 	feasible. If clients require SCTs from more than one log, the likelihood
 	of this attack can be reduced.

Second, the 6962bis work explicitly includes a gossip protocol to
address this. Some even envision all browsers to be gossipers (although
some fear that leaks too much brower history). Regardless, there will
be very many logs/auditors/gossipers. So this is pretty much a red
herring. A first draft was presented last Monday at IETF 92 in Dallas:

http://tools.ietf.org/html/draft-linus-trans-gossip-ct-01

 	Domain owners either have to put their trust in the CA they’ve
 	to correctly monitor all logs 24/7 for fraudulent issuance, or
 	have to monitor all logs themselves (something they are extremely
 	to do).

This is also incorrect. See page 6 of the presentation that Daniel Kahn
Gillmor gave at trans:

http://www.ietf.org/proceedings/92/slides/slides-92-trans-3.pdf

You can see that web clients, when detecting a new SCT or Certificate
will exchange this with the website. This means that the domain owner
receives reports automatically of all rogue certficates once the
web client is no longer under attack and connects to the legitimate
site.


I did not read the blog post further as for why their solution is
better, mostly because I personally (no hats) do not believe in
protocols depending on bulk CPU power and heating up the world.

Paul