# A Blockchain based PKI Validation System based on Rare Events Management
## 4 A New Approach to X.509 Certificate Management Using Distributed Ledger Technology (DLT)
### The Chosen Blockchain Framework  
Hyperledger fabric is a permissioned blockchain framework infrastructure, originally designed by IBM and Digital Asset, which provides a modular architecture with a delineation of roles between the nodes in the infrastructure, execution of smart contracts (called \"chaincodes\" in fabric), and configurable consensus and membership services. A fabric network comprises \"peer nodes\", which execute chaincodes, access ledger data, endorse transactions, and interface with applications; \"orderer nodes\", which ensure the consistency of the blockchain and deliver the endorsed transactions to the peers of the network; and \"MSP services\", which are generally implemented as a \"certification authority\" that manage X.509 certificates which are used to authenticate member identities and roles [12]. To avoid misunderstanding, in the following text, \"certification authority\" refers to the issuers of digital certificates used internally in the fabric blockchain to identify peers, while \"Certification Authority\" or \"CA\" with upper case initials is used to identify the issuers of digital certificates discussed in this research paper. Nowadays, we are used to operating on already instantiated blockchains, such as Bitcoin or Ethereum, where there are a number of peers that run specific programs (for example the program named GETH for Ethereum) that make them able to locally manage all the blocks of the blockchain to propose transactions and to give consensuses. One does not need to know how many peers are active at a particular time on the blockchain, but the bigger that number is, the more secure transactions are. Using the hyperledger fabric framework, instead, a blockchain developer can instantiate his personal blockchain over a given number of organizations. Hyperledger fabric, in fact, is a completely configurable blockchain framework in which it is possible to specify the numbers of organizations and peers participating in the blockchain, and also, to modify the basic modules of the blockchain, such as the certification authority and also the consensus algorithm. In version 1.4.2 of the hyperledger fabric, there are three different consensus algorithms: Solo, Kafka, and Raft. It is for these reasons that we choose the hyperledger fabric framework. In particular, we decided to choose the Raft module, and we modified the way a \"consenter set\" is chosen. Note that in Raft, a consenter set is the set of ordering nodes actively participating in the consensus mechanism for a given channel and receiving replicated logs for the channel. This can be all of the nodes available (either in a single cluster or in multiple clusters contributing to the system channel), or a subset of those nodes. Furthermore, one of the main characteristics of hyperledger fabric is the _permissioned_ approach to the blockchain developed. Only users owning a digital certificate issued by one of the certification authorities configured in the blockchain can launch smart contracts (chaincode methods in the fabric terminology). This is not an implementation limit, and all the users (both CAs and end-users) will have a private key and a public certificate, issued or recognized by the blockchain. In the following, we use the word server instead of domain server; for example, a web server, or in general, the server of a TLS channel, identified by the subject attribute of the X.509 server public key certificate. The aim is to secure the TLS channel establishment between the client and server. With these elements in mind, our blockchain has three classes of peers:  
1. Clients, who, as usual, activate TLS secure connections with a server, receiving the server certificate;
2. Servers with a domain name;
3. CAs. Events that cause transactions are as follows:  
1. Client:* Certificate validation check to establish a TLS channel with a server. * New certificate issuance when the server publishes a new X.509 certificate;
* Certificate revocation when the server certificate is revoked.