Comments

[bisho]

• OCSP stapling solves many issues because the proof of not revocation, signed with time is included in the TLS negotiation. Only the servers do it so does not affect privacy and scales properly because it's only done by the servers on intervals. Clients receive the certificate chain and the proof of validity so they don't need to contact any CRL/OCSP to ensure there were no revocations. The currently unsolved problem in TLS is not revocation. but that the browser trusts too many CAs and there is no easy way to ensure a CA is not signing what it shouldn't. Certificate transparency is trying to solve this.
• The problematic part of self-signed certificates is not revocation, is that anybody can create them for google.com or any domain of their choice. Using one causes that clients can't be sure if there is any MITM. And if MITM is possible because anyone can generate a self-signed cert for your domain, revocation is totally irrelevant. Attackers don't need to steal the real private key of the self-signed certificate, just generate another self-signed on their boxes!!!
• The idea of bitcoin its interesting, but making a transaction with the certificate signature does not prevent anyone of doing the same. At least issue the transaction from the bitcoin address included on the certificate, to ensure the one that controls the bitcoin address is the only one that can issue transactions from there, and the transaction with the hash serves as validation of that the certificate was really issued by that bitcoin address owner. Then arguably a browser can pin a domain to a bitcoin address and only accept self-signed certificates issued by that address. The bad side is that this just translates the problem to protecting the private key of the bitcoin account, but it's true that that could be better protected than the usual ssl private key that is stored on the servers.
• You don't mention how fast will be to clients to verify the bitcoin transaction and account balance status. Just using an api via https is making that api behave as CA, with the same potential problems and compromise issues, not to mention that you are using on https to fetch that info, so again compromised CAs open a world of possibilities. If you really want to go to the source you need to retrieve the whole bitcoin keychains and update them continuously, which are huge, resource intensive and very impractical for clients.

[dblas]

Interesting proposition! But it doesn't cover all the use cases since that requests an online feed. If you think about certificates they were build to carry their own value and to try not to depend upon a external authority. And that the big problem: with a blockchain using BitCoin system you need to have an online access to work with. That's not the philosophy of certificate. The idea is however good but needs to be refined to satisfy this use case. Thank! db