

Certificate Transparency: Public, verifiable, append-only logs - cpach
http://queue.acm.org/detail.cfm?id=2668154

======
MiWDesktopHack
I respect and admire agl, his and very important work on EC; but i must
respectively disagree with his analysis of bitcoin and other blockchain based
technologies.

This paper was written in 2011, and a lot has changed since then. Today, we
have an infrastructure similar to what Certificate Transparency is said to
produce -- without collusion or support from the CAs. Bitcoin and other
blockchain based technologies have an economic incentive to continue to
propagate. I fail to see why anyone other than the CA's would have an
incentive for the Certificate Transparency blockchain to propagate.

I proposed an alternative model which i called 'UTXOC'. I wrote a paper and
published some python scripts to generate certificates based on a prior
bitcoin transaction. A certificate validity can be determined by some bitcoin-
like value left unspent. If the value is spent, the cert if invalid. If the
private key is compromised, the attacker has an economic advantage in 'cashing
out' the value; thus invalidating the certificate. I propose that also adds to
the cost of key substitution attacks on TLS; an active MiTM would need to
spend at least as much cryptocurrency in order to successfully fake a
certificate, even with a trusted root in the client.

It could go either way -- with CA support for such things, or a self-signed
'cryptocurrency bond' style model where TLS operators hold cryptocurrency in
order to maintain the validity of their certs.

This is published here:
[https://github.com/MiWCryptoCurrency/UTXOC](https://github.com/MiWCryptoCurrency/UTXOC)

Very interested to hear opinions on this, its a work in progress. Yes, support
for secp256k1 is limited in mainstream OS's -- it only works with openssl
s_client and s_server currently. Given time I hope that the secp256k1 curve is
added to browsers and operating systems, and this or similar blockchain based
record architectures are adopted.

thanks all ;-)

~~~
evmar
Minor correction: this article was written by Ben Laurie, not agl. (Same
company though.) But you also mentioned 2011 so I'm not exactly sure what you
are referring to.

~~~
MiWThrowaway834
doh! embarassed. your right, Ben Laurie. i recall agl speaking about this
recently, thats the association. Appologies to Ben and Adam :-)

------
MiWThrowaway834
Ok, so the date on this paper is 2014, but wasn't this proposed at least 2
years ago? I recall it being proposed as a countermeasure to the Iranian
Google cert incident.

~~~
cpach
Well, the project itself isn't new. But this article is (relatively) new, and
since it was quite well written I thought it was worth submitting.

I'm not really knowledgable enough to assess the project's vitality but I
found that the Github repo[1] is active, and the mailing list[2] is somewhat
active as well. There is also a new RFC draft from 2014-07-10[3].

My conclusion is that since this project is backed by Google, it's currently
the most viable attempt to improve on the suboptimal PKI infrastructure we
have for TLS.

Ideally Firefox, Safari, Internet Explorer and Opera would add support as
well. Firefox as least has an open feature request[4]. But these things take
time, you know :)

[1] [https://github.com/google/certificate-
transparency/commits/m...](https://github.com/google/certificate-
transparency/commits/master)

[2] [https://groups.google.com/forum/#!forum/certificate-
transpar...](https://groups.google.com/forum/#!forum/certificate-transparency)

[3] [https://tools.ietf.org/html/draft-ietf-trans-
rfc6962-bis-04](https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-04)

[4]
[https://bugzilla.mozilla.org/show_bug.cgi?id=944175](https://bugzilla.mozilla.org/show_bug.cgi?id=944175)

