# A Blockchain-Based Decentralized Public Key Infrastructure Using the Web of Trust
## 3 Shortcomings of a Centralized PKI System
\begin{table}
\begin{tabular}{p{113.8 pt} p{113.8 pt} p{113.8 pt} p{113.8 pt}} \hline \hline
**Schema** & **Features** & **Benefits** & **Drawbacks** \\ \hline [PERSON] et al. [29] & A smart contract-based hybrid X.509\(\times\) scientific that incorporates blockchain metadata. & • & Mitigates compromised CA attacks. Updateable keys & • & Unable to detect counterfeit certificates. Does not hide identities. \\ \hline CertLedger [13] & Certificate transparency and records all issued certificates and revocation status. & • & Avoids split-world attacks. Ensures a reliable validation process. & • & Reliance on CAs. Requires additional information to revoke a certificate. \\ \hline [PERSON] et al. [15] & Leverages TP-Merkle tree data structure for transparency and a fully automated congestion system. Partially addresses scalability issues. & • & Monitors the activities of CAs. & • & Does not store all certificates. Extra storage necessary. \\ \hline CBPKI [16] & Incorporates blockchain and cloud technologies. Decoupling data from the certificate authority & • & Auto-scaling capability. Mitigates D\(\otimes\) attacks. & • & Eliminates the necessity of CRLs, which raises usability concerns. \\ \hline CertChain [17] & Establishes CertOper for storing certificates and enabling forward traceability. Segregates revocation history. & • & Addresses centralization and block-traversal challenges. & • & Increases complexity of revocation. A compromised bookkeeper could compromise security. A avoids using X.509 templates. \\ \hline CertCoin [18] & Manages a public record of domains and associated public keys utilizing Bitcoin, distributed hash tables, and a Merkle accumulator as a CRL. & • & Updateable public keys. Fully public and auditable. & • & Employs larger block sizes. Exhibits logarithmic complexity for new CRLs. \\ \hline CeCoin [19] & Blockchain and web-of-trust-based PKI influenced by Bitcoin. Miners replace CAs. & • & Pevents a single point of failure. Eliminates central CAs. & • & Lack of information about the verification process by miners. \\ \hline DBPKI [28] & A dynamic PKI based on blockchain and the WoT. Any system entity can serve as an auditor and handle revocation tasks. & • & Eliminates a single point of failure and removes the need for CAs. & • & Additional cost overhead for storing revocation data in blockchain. \\ \hline SCPKI [30] & Utilizes Ethereum smart contracts to detect malicious certificates and the WoT for verification. Saves certificate data in the InterPlanetary File System (IDFS). & • & IPFS reduces gas costs. & • & Introduces additional latency on certificate authentication. \\ \hline META\_PKI [33] & A cross-certification approach employing a smart contract on Hyperledger Fabric. It offers distributed authentication by using multiple service providers. & • & Eliminates trust in a central CA. Advanced log-based system. & • & Unable to prevent malicious certificate issuance. Lacks complete transparency. \\ \hline Proposed system & WoT model and blockchain-based PKI. Incorporates trusted key rings and an advanced verification system. Offers faster revocation. & • & Eliminates a single point of failure, MitM attacks, and no central CA. Fully transparent and monitors CA activity. & • & Auto-scaling not supported for larger networks. \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Comparison of the blockchain-based schemas. One common method for revoking certificates involves Certificate Revocation Lists (CRLs), managed by the CA or other trusted parties, where the issuing CA publishes revoked certificates with their serial numbers [2]. However, if the CRL becomes unreachable, clients may experience either an open or closed failure. Additionally, CAs, even in the event of a breach, may not be entirely trustworthy in containing or reporting incidents due to financial incentives and reputational concerns, often choosing not to disclose data breaches or operational errors. * **Lack of Transparency:** In the current system, a CA can issue a certificate for any individual domain owner.