# 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 Smart Contract Structure and Its Relationships with the Consensus Algorithm  
The structure of the smart contracts to be implemented is given by the types of transaction executed by the peers (see Section 4.1). The most important one is the smart contract used to validate a public key certificate. The primary requirement we have decided to adopt is that the behavior of the system must be as adherent as possible to the current validation procedures done during web sessions. In order to do so, let us examine the process flow followed by a browser when it connects to a server secured by HTTPS protocol:  
1. Check if the certificate is structurally valid and not expired;
2. Check if the certificate received from the server has been signed (directly or indirectly via a secure chain) by a root CA listed in some locally stored archives (trusted root CA or trusted intermediate CA);
3. If previous checks are OK, check the revocation against locally stored CLRs or against OCSP or using CA logs, as described in a previous section of this paper. 4. Alternatively, if one or more of the checks give KO: 1. If allowed by the local policies of the browser and the O.S. (operating system), the user is asked, with an alert, if he wants to continue with the insecure server;  
Figure 1: Explanation of the Cons algorithm. The size and the selection procedure of the subset of peers are crucial steps in our proposal. 2. Otherwise, the operation is interrupted, and the connection is closed. This is the usual behavior of browsers when we try to connect to known or unknown HTTPS servers. To be considered acceptable, our solution must have a similar behavior. Let us examine the implementation of the smart contract used to validate a public key certificate. The name of the smart contract is Validate, and the required parameters are the Public key certificate, server domain name, and server IP number. Note that the IP address is not always unique, since, in some organizations, security policies require the use of NAT (network address translation) solutions that mask the public IP numbers of the servers, making them useless. However, in most cases, servers' IPs are unique, at least over the Internet. A short implementation of the Validate smart contract follows (Algorithm 1). Consider that the status of a certificate inside the blockchain has been set by other smart contracts (i.e., when a CA revokes a certificate, the information is stored in the blockchain using a specific smart contract). ```
1 Procedure Validate (certificate, domainName, ipAddress)
2{//Return values: VALID, REVOKED, EXPIRED, FAKE
3 findvalue forkey=(certificate,domainName,ipAddress)
4 if(found)
5{
6 Ifvalue is in (REVOKED,EXPIRED, FAKE)
7 returnvalue
8 else if (the tuple =(certificate,domainName,ipAddress) is in the blockchain and has been flagged as correct )
10 returnvalid
11 else
12{
13 **ok =** check the certificate on internet (try to connect to the server) and verify that the certificate sent by the server is identical to the checked certificate
15 if(**ok**)
16 storekey in the blockchain withvalue=VALID
17 returnVALID
18 else
19 storekey in the blockchain withvalue=FAKE
20 return FAKE
21}
22}
23 else{
24 **ok =** check the certificate on internet (try to connect to the server) and verify that the certificate sent by the server is identical to the checked certificate
25 if(**ok**)
26 storekey in the blockchain withvalue=VALID
27 return VALID
28 else
29 else
30 storekey in the blockchain withvalue=FAKE
31 return FAKE
32}
```  
**Algorithm 1** Pseudo code of the smart contract procedure used from a client to validate an X.509 certificate received in the starting phase of a TLS connection. It is important to note that the algorithm also manages the case of a new server and a new associated certificate when the CA and the server involved are not in the blockchain.