[westurner]

From "REMME – A blockchain-based protocol for issuing X.509 client certificates" https://news.ycombinator.com/item?id=18868540 :

""" In no particular order, there are a number of blockchain PKI (and DNS (!)) proposals and proofs of concept.

"CertLedger: A New PKI Model with Certificate Transparency Based on Blockchain" (2018) https://arxiv.org/pdf/1806.03914 https://scholar.google.com/scholar?q=related:LF9PMeqNOLsJ:sc...

"TABLE 1: Security comparison of Log Based Approaches to Certificate Management" (p.12) lists a number of criteria for blockchain-based PKI implementations:

- Resilient to split-world/MITM attack

- Provides revocation transparency

- Eliminates client certificate validation process

- Eliminates trusted key management

- Preserves client privacy

- Require external auditing

- Monitoring promptness

... These papers also clarify why a highly-replicated decentralized trustless datastore — such as a blockchain — is advantageous for PKI. WoT is not mentioned.

"Blockchain-based Certificate Transparency and Revocation Transparency" (2018) https://fc18.ifca.ai/bitcoin/papers/bitcoin18-final29.pdf

https://scholar.google.com/scholar?q=related:oEsKmJvdn-MJ:sc...

Who can update and revoke which records in a permissioned blockchain (or a plain old database, for that matter)?

Letsencrypt has a model for proving domain control with ACME; which AFAIU depends upon DNS, too. """

TLA references "Certificate Transparency Using Blockchain" (2018) https://eprint.iacr.org/2018/1232.pdf https://scholar.google.com/scholar?q="Certificate+Transparen...

[fedotovcorp]

Thanks for the references! The main issue isn't the support and maintenance of a such distributed network, but its integration with current solutions and avoiding centralized middleware services that will weaken the schema described in the documents.

[westurner]

> The main issue isn't the support and maintenance of a such distributed network,

Running a permissioned blockchain is nontrivial. "Just fork XYZ and call it a day" doesn't quite describe the amount of work involved. There's read latency at scale. There's merging things to maintain vendor strings,

> but its integration with current solutions

- Verify issuee identity

- Update (domain/CN/subjectAltName, date) index

- Update cached cert and CRL bundles

- Propagate changes to all clients

> and avoiding centralized middleware services that will weaken the schema described in the documents.

Eventually, a CDN will look desireable. IPFS may fit the bill, IDK?

[fedotovcorp]

> Running a permissioned blockchain is nontrivial.

You are right. It's needed a relevant BFT protocol, a lot of work with masternodes community and smart economic system inside. You can look at an example of a such protocol: https://github.com/Remmeauth/remme-core/tree/dev

[westurner]

google/trillian https://github.com/google/trillian

> Trillian is an implementation of the concepts described in the Verifiable Data Structures white paper, which in turn is an extension and generalisation of the ideas which underpin Certificate Transparency.

> Trillian implements a Merkle tree whose contents are served from a data storage layer, to allow scalability to extremely large trees.