# A Blockchain based PKI Validation System based on Rare Events Management
## 3 Existing Solutions  
Existing solutions to the listed problems can be grouped in three main classes, as shown in the following. In the first class, there is a group of solutions based on the creation of one or more servers that operate in parallel to already existing servers (for example, OCSP servers). Their task is to answer questions about the validity of a certificate. They have to be efficient, fast, secure, and simple. In this class falls the so-called log-based PKI schema, where highly available public log servers monitor and publish a log of the certificates issued by the CAs, ensuring that only the certificates listed in the published logs shall be accepted and trusted by end-customers. Google's certificate transparency (CT) [9] is the most widely deployed log-based PKI (it is available in Chrome and Firefox). Proposals have been done to extend the log also to the revoked certificates, without reaching widely adoptable solutions [10]. This class also includes OCSP solutions that try to support CRLs or other error handling solutions supporting certificate revocation. The idea here is to create a super-CA that coordinates and supports the tasks of the other CAs. However, these solutions suffer from the same fragilities of standard, traditional PKIs because the underlying architecture is essentially the same. In the second class, there is a group of solutions that come from decentralized networks of peer-to-peer certification, known as the web of trust (WoT). The main example of a WoT is PGP (pretty good privacy) where a trust function built on a social network replaces the concept of authority and the classical CA. In our contest, this trust function can be used to enforce a certificate in its link between a subject and a public key. Like PGP, users are able to designate others as trustworthy by signing their public key certificates. By doing so, a user accumulates a certificate containing his public key and digital signatures from entities that have deemed him trustworthy. Problems exist with new users and with CRL management. We think that this is a promising solution that has not yet been fully explored. In [11], PKI interoperability is studied in detail. The paper covers all aspects behind the existing scenarios and the conclusive thesis is that there is a **trust management problem**. Only a new authority could solve this problem, but there is not a hierarchical structure that keeps together root certification authorities. In [11] the proposed solution is to define a trust broker, a new actor with the goal to evaluate the CAs objectively, and their certificates, and to send recommendations to relying parties (RP) to help them to make informed decisions about these certificates. \begin{table}
\begin{tabular}{c c c} \hline \hline
**Class** & **Attack** & **Consequence** \\ \hline
**CA side** & \
\begin{tabular}{c} Fake CA \\ Fake CA in the client store \\ Certificate/private key stolen with server \\ \end{tabular} &
\begin{tabular}{c} Issuing and distribution of fake server \\ certificate \\ Man in the middle attack \\ Server udicate/Man in the middle \\ attack \\ \end{tabular} \\
**CRI/OCSP** & \
\begin{tabular}{c} Certificate/private key stolen without \\ server awareness \\ Delay in CRL issuing \\ Fake CFL address in fake server certificate \\ \end{tabular} &
\begin{tabular}{c} Server duplicate/Man in the middle \\ attack \\ Attack \\ \end{tabular} \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Summary of attacks grouped into classes. CA: certificate authority; CRL: certificate revocation list. The paper specifies that the relation between the trust broker and the RPs must be regularized by explicit agreements. In such agreements, the trust broker recognizes its responsibility to the RPs about the provided recommendations and requires itself to respect and to protect the privacy of the RPs. On the other hand, the trust broker must be independent from the CAs.