[Cryptography] A PKI without CRLs or OCSP

[Francisco Corella]

Tony,

> > [...] remarkable advantages.  In particular, the verifier can validate
> > a certificate chain on its local copy of the blochain
> 
> The disadvantage is every client needs a copy of the entire blockchain
> / log.

Storing a copy of the entire blockchains seems a big deal...  But
somehow Bitcoin or Ethereum clients don't seem to have any problem
with it.  And in our use case (see below), the verifier is not a
pc or a mobile device, it's a server in a data center.

> There's already a system in place that works much like a
> blockchain for certificates: Certificate Transparency logs:
> 
> https://mikecborg.wordpress.com/2016/10/25/googles-ct-logs-and-purposes/
> 
> Unfortunately these logs have such high volume that nobody but Google
> can presently operate one capable of handling Let's Encrypt, let alone
> trying to push that volume of data out to every client so they have a
> local copy of every certificate.

In a blockchain implementation, the data that is "pushed out" is not
certificates, but hashes of certificates.  And the pushing out is
accomplished by the peer-to-peer communications that update the local
copies of the blockchain, which seem to work without any problem.

> > without any network access
> 
> What's the use case? I'll note with OCSP stapling a client can
> validate a certificate chain with only network access to the
> destination service whose certificate they're trying to validate. You
> seem to be talking about verifying certificates in a context where you
> aren't even trying to initiate an SSL/TLS connection?

The use case is remote identity proofing, for purposes such as
applying for a mortgage, or registering to obtain a government
service, or signing on to become a driver for an app-based ride
service.  The goal of the project is to find alternatives to the
ineffective and privacy-invasive method of asking the subject multiple
choice "knowledge questions" (e.g. which of the following zip codes
did you live in five years ago?).  One alternative that we are working
on involves having an identity source store a cryptographic credential
in the subject's browser, which is presented by a service worker to
the verifier.  (More specifically, the credential that we are
considering is a "rich credential" that supports three-factor
verification, but which cryptographic credential is used does not
matter for revocation.)

Francisco