Pomcor has just been granted US Patent 10,764,067, “Operation of a Certificate Authority on a Distributed Ledger”. A distributed ledger is a database replicated across of set of nodes and populated by transactions issued by the nodes. A distributed consensus algorithm is used to achieve consensus among the nodes on the order of the ledger transactions. A blockchain is a distributed ledger in which ledger transactions are grouped into blocks, and consensus on the ordering of the ledger transactions is based on consensus on the validity and ordering of the blocks.
Some distributed ledgers, e.g. the Ethereum blockchain, provide on-ledger storage by allowing a ledger transaction to contain an instruction to store data in an abstract ledger store identified by a ledger address. As ledger transactions including such instructions are propagated to the nodes of the ledger through the peer-to-peer protocol each node executes the instruction locally, on a local replica of the abstract ledger store that is part of the node’s local replica of the ledger state.
A public key infrastructure is a system for issuing, revoking and validating public key certificates, implemented by a hierarchy of certificate authorities (CAs). The storage replication functionality provided by a distributed ledger with on-ledger storage can greatly simplify the implementation of a PKI.
I do not advocate setting up a blockchain or other distributed ledger just for the purpose of implementing a PKI. But if a distributed ledger has already been set up or is being set up for some other purpose, it can be opportunistically used to implement a PKI, or to simplify the operation of an existing PKI.
I also do not advocate storing or transmitting certificates on the blockchain. That would be a bad idea for privacy reasons, and there is no need to do so. A CA operating on a distributed ledger can issue any kind of certificates, including certificates whose subject is a machine, such as a web server or an IoT device, and certificates whose subject is a person. Each kind of certificate can be stored together with the corresponding private key in any kind of secure storage customarily used for that kind of certificate. In a presentation at ICMC 2017 I explained how JavaScript Web APIs can be used to store personal cryptographic credentials in the browser.
Here is a summary of how a PKI can be implemented on a distributed ledger; details can be found in the patent. A subject requests a certificate as usual by submitting a certificate signing request (CSR). The CA creates a certificate and transmits it to the subject, without ledger involvement in the transmission; there is no need for the subject to have access to the ledger. But the CA also issues an issuance transaction on the ledger with an instruction to store a cryptographic hash of the certificate in a certificate issuance store controlled by the CA; and when the certificate needs to be revoked, it issues a revocation transaction on the ledger with an instruction to store the serial number of the certificate in a certificate revocation store also controlled by the CA. As those transactions propagate throughout the ledger, the instructions are executed by all the nodes in their local replicas of the stores.
This greatly simplifies the process of verifying that a certificate is valid.
Instead of verifying the signature on the certificate, the verifier can just check that the hash of the certificate is present in the certificate issuance store controlled by the CA that has issued the certificate. In fact, the signature can be omitted from the certificate if all verifiers have access to the ledger, substantially reducing the size of the certificate and thus the bandwidth and latency cost of presenting the certificate.
And the verifier can check that the certificate has not been revoked simply by checking that its serial number is not present in the certificate revocation store controlled the CA. This obviates the need for the CA to provide a highly available Online Certificate Status Protocol (OCSP) server and/or a regularly updated Certificate Revocation List (CRL); and for the verifier to query the OCSP server or maintain a local copy of the CRL by periodically retrieving signed updates.