[Cryptography] A PKI without CRLs or OCSP

[Jerry Leichter]

> While working on a blockchain-based solution for remote identity
> proofing, we came to realize that a blockchain with on-chain storage
> can be used to implement the same functionality as a traditional PKI,
> with remarkable advantages.  In particular, the verifier can validate
> a certificate chain on its local copy of the blochain without any
> network access.  Details can be found in this blog post <https://pomcor.com/2016/10/25/implementing-a-pki-on-a-blockchain/> and in Section
> 3 of this paper <https://pomcor.com/techreports/BlockchainPKI.pdf>.  Comments welcome.
How does using a blockchain differ from having a PKI broadcast its entire set of signed public certificates?  Or, equivalently for reasonable efficiency, every delta to its set?  (With a serial number, of course - and the entire delta signed by the CA - so that receivers could detect modifications or missed deltas.)

A blockchain supports agreed-to modifications by anyone (to simplify the semantics). But a PKI has just one sender, broadcasting to many receivers.  You don't need a blockchain for that, just signatures.

A CRL blockchain - on which anyone could mark their own certificate as canceled - might make more sense, but even here it's the wrong semantics.  If I believe my certificate should be invalidated ... that's *my* call and my call alone.  The last thing I want to have to do is get a whole bunch of others on the blockchain to agree with me that it should be invalidated - it's *my* call, not theirs.  My signature alone on the invalidation is sufficient proof that I sent the invalidation and it should be honored.  I want some form of reliable broadcast to ensure that my invalidation has reached all the relevant parties, but that's a much weaker (and cheaper to produce) primitive than a blockchain.
                                                        -- Jerry


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20161026/6fdedb58/attachment.html>