
Can we merge Certificate Transparency with blockchain? - fedotovcorp
https://www.reddit.com/r/hacking/comments/aibw8b/does_certificate_transparency_need_blockchain_for/
======
westurner
From "REMME – A blockchain-based protocol for issuing X.509 client
certificates"
[https://news.ycombinator.com/item?id=18868540](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://arxiv.org/pdf/1806.03914)
[https://scholar.google.com/scholar?q=related:LF9PMeqNOLsJ:sc...](https://scholar.google.com/scholar?q=related:LF9PMeqNOLsJ:scholar.google.com/&scioq=&hl=en&as_sdt=0,43&scilib=1)

" _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://fc18.ifca.ai/bitcoin/papers/bitcoin18-final29.pdf)

[https://scholar.google.com/scholar?q=related:oEsKmJvdn-
MJ:sc...](https://scholar.google.com/scholar?q=related:oEsKmJvdn-
MJ:scholar.google.com/&scioq=&hl=en&as_sdt=0,43&scilib=1)

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://eprint.iacr.org/2018/1232.pdf)
[https://scholar.google.com/scholar?q="Certificate+Transparen...](https://scholar.google.com/scholar?q="Certificate+Transparency+Using+Blockchain"&hl=en&as_sdt=0,43&scilib=1&scioq="Certificate+Transparency+Using+Blockchain")

~~~
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](https://github.com/Remmeauth/remme-core/tree/dev)

