A very essential certificate standard is the X.509 standard. The X509 certificates are of two types: namely public key certificate which combines public keys to a subject as stated earlier and attribute certificate that binds attributes such as roles to a subject. There are also however alternatives to the X509 certificates [17].

The term certificate in this context refers to the x509 public key certificate standard which is also referred to as public key certificate. X509 is the certificate format issued by certificate authorities to both CAs and end users alike [8].

Public key Certificates remain the most critical piece of component to the operations of PKI. Certificates to a large extent are public keys which have been signed by trusted CAs and can be distributed publicly like any file for instance word document file. Certificates contain data and have format similar to any type of file with format. Figure 2 is an overview of the certificate structure.

Further Figure 3 is sample generated private and public key using a key management software.

For the purposes of illustrating a signed certificate, Figure 4 shows a key that has been signed by the certificate authority hence is now a public key.

PKI architecture is premised on the quantity of CAs involved, their organization, and the association between them [9]. The need for different PKI architectures, also known as trust models by industry players, largely depends on varied needs and processes of business, this implies that, PKI trust models are as a result of the requirements and demands of business. “Direct trust is the most basic trust model, it is therefore required by all other trust models to initialize trust” [12]. This implies that for any kind of architecture or trust model, there must exist some form of direct trust without which no trust can be initialized. This therefore implies that trust must start from somewhere and be propagated to where it is needed. Direct trust is the highest form of trust and it is obtained when users directly acquire the public keys of CAs directly from the CA via out of band means. For example, embedding the public keys of Digicert in Firefox or Microsoft browsers.

For such trust models to be functional, just as users need to trust CAs, CAs in an infrastructure need to trust each other. A basic component of PKI is that public keys, usually structured as signed certificates, must be trusted. The inability to

ensure the required level of trust causes the entire PKI to negatively experience a grave “weak link in the chain” [18].

The PKI architecture types have no single point of view that exists today especially on the naming conventions used. Different types of PKI architecture have been discussed in many literatures. However, all these types can be grouped into three main categories due to similarities in their operations.

According to [10], “PKI architectures can be implemented in the following ways: Single CA architecture, Enterprise PKI architecture and Hybrid PKI architecture”. However, [18], suggest that the general construction of a PKI is denoted as non-hierarchical, hierarchical, or cross-certified.

This research work operationalizes the definition of Choudhury et al. with three main PKI trust models.

A single CA Architecture or Single trust model involves only one CA and all users trust this single CA. This CA explains the set of certificates that it can verify and trust.

A PKI with a single CA architecture suffers from scalability issues, single point of failure, difficulty of management and limited scope, etc. These limitations motivated the various models with multiple CAs with different arrangements. In other words, PKI architecture is defined by the number of CAs providing the PKI services, and roles played by the CAs defines their relationship. Users in a single CA model cannot be trusted, by users in another CA since there is no trust between the CAs and they operate independently. This implies that there is no interoperability between users and CAs in single CA models whiles, interoperability remains very important to the growth of business.

Single CA model is capable of addressing the requirements of small organizations, this tends to be however inadequate in situations where the organization’s requirement grow with the need to be interoperable and requirements tend to be more complex. This is typically the operations of a single CA to be distributed and arranged between multiple CAs. PKI services are provided by multiple CAs; a tiered construction with subordinate CA relationships in which all users trust a single “root” CA. Its operation requires the root CA to issue certificates to subordinate CAs only, the subordinates can issue certificates to users or CAs in lower levels of the hierarchy. The trust relationship is specified in only one direction, and every certification path begins with the root CA’s public key. There must exist direct trust for the root CAs for the system to be trustworthy.

In a tiered or hierarchical PKI, trust in the genuineness of a public key is established via a certification path. If a CA is the entity of a certificate issued by another CA, the certificate is called a cross certificate. In hierarchical model, there are a number of cross certifications. “A list of cross certificates needed to allow a particular user to obtain the public key of another entity, is known as a certification path. In a hierarchical PKI, trust in the authenticity of a public key is established via a certification path” [12]. The most common PKI architecture deployed by organizations is the Hierarchical [9]. This assertion is confirmed by [19], it is explained that a root CA at the topmost delivers all the information and the in-between CAs in the tiered structure only trust information provided by the root. The root CA also trusts in-between CAs that are in their level in the tiered structure.

This arrangement allows a high level of control at all levels of the hierarchical tree. Thus, hierarchical models allow tight control over certificate-based activities.

Certificate path is a predetermined arrangement of certificates with the predefined features that in all related certificates with the exception of the last one operate on the premise of the subject being the issuer of the subsequent certificate. Certificate path validations are performed by algorithms known as certification validation algorithms. These algorithms verify that a given certificate path is valid under a given public key infrastructure (PKI).

When a relying party such as Alice in Figure 5, is presented with any certificate she does not already or explicitly trusts, Alice will use path validation to make an informed trust decision.

In Figure 5, Alice trusts the public key of Diana, however, for the trust to be established, the following path validation is used. The chain commences with the certificate that is self-signed by the root CA. The subsequent has the root CA certifying the public key of CA2. The third certificate then has CA2 certifying the public key of Diana.

A challenge associated with the CA’s hierarchical model of trust relationships is that in the event that the root CA’s private key is compromised, the entire tiered structure of the CAs and end entity certificates collapses. Essentially, if a CA’s private key is ever compromised, the breach could be leveraged to falsify messages in-between entities, in the event this is reliant on a certification path that includes that of the CA’s and possibly many paths are routed through the CA, it

invariably provides an available target for security breach attacks. Should a key be compromised, it can no longer be trusted and should be replaced [20].

In 2011 two important root Certificate Authority, Comodo and DigiNotar, were compromised. “The attacker who penetrated the Dutch CA DigiNotar had complete control of all eight of the company’s certificate-issuing servers during the operation and he may also have issued some rogue certificates that have not yet been identified” [21].

The case of compromise of the certificate vendor called Comodo, the culprit said he has successfully breached another CA, in addition to two more Comodo partners [22]. Security is considered to be a chain; it is therefore considered to be only as strong as its weakest link. This involves people, technology and processes, not everything is dependent on cryptography, [23], an employee from StartCom was able to get a domain certificate for “mozilla.com” from CertStar, a Registration Authority of Comodo. There was no validation at all at the Registration Authority in the certificate request [16].

The certification model for X.509 concentrates validation power into the hands of a few professionals, who are not necessarily well-intentioned, or at least not always competent. [24]. Failure of a CA signing key is catastrophic; keys could be compromised without anyone’s knowledge. The possible compromise of a CA’s private key signifies a single point-of-failure0 has the potential to create far reaching consequences [25].

Just like any system, there is no such thing as 100% security proof. PKI suffers from various attacks. Equally, there have been different, and variants proposed solutions from industry players to remedy such security breaches and reduce the attack surface of PKI.

In summary, it is important to understand some fundamental principles that ensure inter-domains certificate validation possible. There are multiple CAs in the Hierarchy model as stated earlier, there is a root CA and subordinate CA and the end entities. For cross certification purposes, it is required that CAs will issue certificates to other CAs, whereas some CAs issue certificates to end entities or users, this implies that, there are two primary types of public key Certificates: user certificates and CA certificates.

Public Key Infrastructure is well noted for some strengths; it is considered relatively more secure than passwords. Malevolent users or attackers must obtain both the private key and the matching passphrase to fake as a legitimate user, PKI in this context provides stronger identity checking through secret private keys [26]. PKI is greatly scalable because there is no limit to the number of users who can be supported using PKI [27]. The permission of the trust delegation in PKI prevents man-in-the-middle (MitM) attacks, this is a result of its possibility without knowledge of the key pair. This is possible once a user with a legitimate certificate from a recognized and trusted certificate authority is able to authenticate himself to a server the very first time. The connection to the server is possible without having previously been registered with the system. This makes it possible for the PKI to enable a trustworthy setting by validating and ensuring the integrity of data and users. The keys within PKI established systems can be used for one-way encryption functions where only the designated owner of the key can decrypt data. [28]. PKI also has the benefit of private keys which are difficult to crack together with the corresponding public key. “As such, it features cryptographic protection that passwords lack: passwords do not necessarily have a verifiable, computable relationship with anything” [29]. PKI enables added service offerings such as banking, law, health care, e-commerce and intelligence, through the use of digital signatures and digital certificates. It detects tampering and allows for non-repudiation [30]. The seamless, ease and non-interactive use of PKI is key strength and driver for PKI’s overall acceptance.

Certificate Authorities have had several slips where they issued certificates without adhering to rules. CAs have issued SSL certificates that have been used to perform man-in-the-middle (MitM) attacks and intercept HTTPS traffic have been used for malware operations or CAs issued certificates without following standard procedures because of human errors, accident, or to cut costs and increase profits [16]. As long as certificate issuance remains a business, the motivation to increase profit and cut down cost is eminent. Thus, according to the report, CAs issue certificate without following standards. Such standards include subscriber validations which can be costly especially for extended validations (EV). “Extended validation is costly. CAs need to employ different information sources, undergo additional CA/Browser forum procedural steps and pay for additional third-party audits to issue EV certificates. Companies require additional employee training, internal audit systems and the like which all translate into cost” [31]. It therefore makes economic sense to cut cost and increase profit. The main PKI weakness is that, a certificate can be signed by any certificate authority for an individual or machine. There is also the situation where certificate authorities are made coerced to certificates for entities they have no business vouching for [32].

The certification model for X.509 essences endorsement power into the hands of a few specialists, who are not necessarily always competent or well-intentioned. When a CA is not well-intentioned, it could issue rogue certificates, and will not adhere to standards and best practices. PKIs are heavily dependent on the integrity CAs and RAs, these CAs and RAs aren’t always necessarily functional at the perfect professional level of conscientiousness and scrutiny [33].

This incident emphasizes the possibility of CAs to issue certificate to domains without validation. It also implies that CAs can issue certificate without the permission or authorization of domain owners.

Additionally, a security lapse of Public Key Infrastructures today is the lack of multi-factor authentication on many of the top frameworks [33] (Venafi education, 2019). CA can use keys fraudulently, negligently, erroneously or mistakenly without detection. The keys can be lost or stolen, that is, keys can be misused or lost. CA and RA are considered as trusted parties in PKI, likewise in cryptographic literature, this perception of trust however cannot be evidenced or confirmed with certainty.

Failure of a CA signing key is catastrophic; keys could be compromised without anyone’s knowledge. The management and revocation of certificates requires a highly complicated structure. Complexity is a weakness of PKI Visibility.

The essentially deduced Public Key Infrastructure weaknesses identified are therefore namely uncertain integrity, absence of multi-factor authentication, insufficient proof of trust and the potential of a single point of failure

1) Requests for Registration: The stage of the process involves the subscriber applying to a registration authority to obtain signed certificates.

2) Store Subscriber Information: The registration authority registers the subscriber and stores the subscriber details in the public repository to make subscriber information publicly searchable and visible.

3) Generates Public and Private Key Pair: The subscriber uses a key management system to generate keys to be made available for signing.

4) Verify Subscriber Information: The certificate authority validates authenticity of subscription/application and then signs the keys.

5) Sign Certificate: Certificate authority signs the keys to certify subscription.

6) Store Certificate in Transparency Log: The certificate authority proceeds to store the certificate in transparency log to make certificate publicly available.

7) Search Public Repository: The certificates are made available and searchable in the public repository for relying entities to access certificates for use.

Comparatively, the process described in Figure 1 conspicuously omits the storage of subscriber information for public accessibility, mandatory verification of subscriber information to validate authenticity and the collaboration of two certificate authorities to sign and certify the subscriptions as compared to Figure 6. The dependencies proposed in Table 1 provide a premise for the respectively outlined stages.

The proposed solution eliminates potential mistakes, errors, forgery and impersonation during enrolment. Multiple validation processes by different CAs with different approaches to information gathering and validation methods will not capture the same mistakes and errors, rather it will assist in capturing any inconsistencies.

Detection of unlawful or wrong entry in the registration record can be easily detected since those records are publicly available and searchable. It is also possible to write simple scripts to automatically monitor the online repository for specific domain entries to immediately detect any anomaly or unauthorized entries.

It provides certificate governance and reduces autonomous operation since CAs cannot operate in isolation or issue out certificate without the cooperation of the online repository, the subscriber and the issuing CAs. This implies that certificate issuance is not centrally controlled or monopolized, thus PKI operations are distributed

The proposed solution ensures accuracy of subscriber records as records can be monitored continuously with very little efforts to immediately detect any suspicious entries for specific domains. Because the online repository is searchable and read only, only authorized entities can modify the entries which ensures that accurate records are maintained.

CAs will police each other, this will ensure high level of compliance and adherence to best practices and standards without compromising to save cost or resources. It will ensure quality in the overall validation process whiles enforcing the procedures.

As the validation records are made public, the subscriber can later detect errors or mistakes for immediate corrections. It also implies that once the online data is correct, it can guarantee the accuracy of the certificate to be issued and the validation process of the relying parties.

The included novel component of storing subscriber information for public accessibility impacts positively on both trust of registration authority and integrity of the process and ultimately the certificate authority, the component of mandatory verification of subscriber information to validate authenticity also impacts positively on trust and integrity of the certificate authority and the process. The component of collaboration of two certificate authorities to sign and certify the keys in the PKI validation process prevents a possible single point of failure. This is illustrated in Table 2.

At the point of registration, the subscriber decides and indicates the preferred certificate authorities and essentially has this information stored and publicly visible. The usage of two certificate authorities subsequently prevents the possible single point of failure in the event that one certificate authority is compromised. Browsers would require re-configuration to ensure that they check for two certificate authorities in signed certificates.

Trust is the safe confidence in the competence of an individual or entity to act securely, dependably, reliably and timely within a specified context.

To prove the existence of trust means to prove the reliability of the trust. The proposed framework requires both participation of the subscriber and the CA. The CA alone cannot operate in isolation. An attempt to sign a certificate for a domain without the approval of the domain owners or pre-registration by the would-be subscriber will fail since the owner approval is required before signing can be executed. Thus, because signing of a certificate in the proposed system requires permission and authorization from domain owner, it is easy to prove or verify the trustworthiness of the infrastructure. Thus, the subscriber is not just trusting the CA to only do what is expected of it, but it can be proved that the CA cannot secretly execute harmful unauthorized task on its own. The reliability and dependability of the proposed solution is improved.

Integrity is the assurance of data being complete, consistent and free from any form of corruption. In this context, it is the subscriber who requires assurance that information provided, stored and recorded cannot be altered.

Only domain owners could initiate and authorize certificate signing requests, only authorized certificate authorities could sign certificates and only authorized administrators could have access to the signing private keys protected with multi factor authentication. Thus, all stake holders need to be compromised to undermine the integrity of the proposed framework. One would notice if the secure key for multifactor authentication went missing, so a private signing key being protected by the missing secure key could be revoked immediately before it is compromised by an attacker.

Predominantly, browsers are required to consider multiple certification paths pending the discovery a valid one for a given certificate. “Constructing and evaluating all possible paths is an expensive process performed for every new certificate a browser encounter” [34].

This implies that, for a certificate to be verified, a browser would have to obtain a series of certificates referred to as a certification path each one having signed the next certificate in the sequence, connecting the signing CA’s root which is the trust anchor to the server’s certificate called the leaf. Longer certification paths take much time and require more resources to process.

In the proposed solution, the registration record also serves as trusted anchor validation database. Every issuing or intermediate CA in the registration record would have been vetted, validated and approved by the trusted anchors, therefore, there is no need to construct longer certification path chains from the leaf to the anchor by browsers. This reduces the certification path length. The issuing CAs certificates are the only required certificates in the certification path. Therefore, the time it takes to construct, validate and process certificates for verification is expected to minimize, consequently minimizing resource utilization by relying parties.