Authority And PKI Trust System: The Facts

Understanding Authority And PKI Trust System

 

Internet traffic consists of traffic between two parties. When establishing an asymmetric connection between two hosts, the hosts will exchange their public key information. An SSL certificate is a digital certificate that confirms the identity of a website domain. To implement SSL on your website, you purchase an SSL certificate for your domain from an SSL Certificate provider. The trusted third party does an in-depth investigation prior to the issuance of credentials. In this article, I want to talk about Authority and PKI Trust System. 

After this in-depth investigation, the third-party issues credentials (i.e. digital certificate) that are difficult to forge. From that point forward, all individuals who trust the third party simply accept the credentials that the third-party issues. When computers attempt to connect to a website over HTTPS, the web browser checks the website’s security certificate and verifies that it is valid and originated with a reliable CA.
 
This validates that the website identity is true. The certificate is saved locally by the web browser and is then used in subsequent transactions. The website’s public key is included in the certificate and is used to verify future communications between the website and the client.

 

These trusted third parties provide services similar to governmental licensing bureaus. The figure illustrates how a driver’s license is analogous to a digital certificate.
The Public Key Infrastructure (PKI) consists of specifications, systems, and tools that are used to create, manage, distribute, use, store, and revoke digital certificates. The certificate authority (CA) is an organization that creates digital certificates by tying a public key to a confirmed identity, such as a website or individual. The PKI is an intricate system that is designed to safeguard digital identities from hacking by even the most sophisticated threat actors or nation-states.

 

Some examples of Certificate Authorities are IdenTrust, DigiCert, Sectigo, GlobalSign, and GoDaddy. These CAs charge for their services. Let’s Encrypt is a non-profit CA that offers certificates free of charge.

The Public Key Infrastructure

PKI is needed to support the large-scale distribution and identification of public encryption keys. The PKI framework facilitates a highly scalable trust relationship.
It consists of the hardware, software, people, policies, and procedures needed to create, manage, store, distribute, and revoke digital certificates.
 
The figure shows a user at a pc with the words PKI certificate above it and a circled number one. There is a circled number 2 beside the computer with the words certificate store. To the right of the user is a circled three public building icon labelled PKI certificate authority and to the right of that is a circled four and a cylinder labelled certificate database.

The next figure shows how the elements of the PKI interoperate:

  • In this example, Bob has received his digital certificate from the CA. This certificate is used whenever Bob communicates with other parties.
  • Bob communicates with Alice.
  • When Alice receives Bob’s digital certificate, she communicates with the trusted CA to validate Bob’s identity.
An arrow goes to a computer user labelled bob that has the circled number two beside it an arrow leading to the Alice computer user with the words exchanges PKI certificate. Above the Alice computer are the words verifies the PKI  certificate, a circled number 3, and an arrow that points back to the certificate authority.
Note: Not all PKI certificates are directly received from a CA. A registration authority (RA) is a subordinate CA and is certified by a root CA to issue certificates for specific uses.

The PKI Authorities System

Many vendors provide CA servers as a managed service or as an end-user product. Some of these vendors include Symantec Group (VeriSign), Comodo, Go Daddy Group, GlobalSign, and DigiCert among others.
Organizations may also implement private PKIs using Microsoft Server or Open SSL.
CAs, especially those that are outsourced, issue certificates based on classes that determine how trusted a certificate is.
The table provides a description of the classes. The class number is determined by how rigorous the procedure was that verified the identity of the holder when the certificate was issued. The higher the class number, the more trusted the certificate. Therefore, a class 5 certificate is trusted much more than a lower-class certificate.
Class Description
0 Used for testing in situations in which no checks have been performed.
1 Used by individuals who require verification of email.
2 Used by organizations for which proof of identity is required.
3 Used for servers and software signing. Independent verification and checking of identity and authority is done by the certificate authority.
4 Used for online business transactions between companies.
5 Used for private organizations or government security.
For example, a class 1 certificate might require an email reply from the holder to confirm that they wish to enrol. This kind of confirmation is a weak authentication of the holder. For a class 3 or 4 certificates, the future holder must prove identity and authenticate the public key by showing up in person with at least two official ID documents.
Some CA public keys are preloaded, such as those listed in web browsers. The figure displays various VeriSign certificates contained in the certificate store on the host. Any certificates signed by any of the CAs in the list will be seen by the browser as legitimate and will be trusted automatically.
The figure shows the certificates window with a highlighted certificate on the trusted root certification authorities tab of Certum Trusted Ne.. issued by Certum Trusted Netw... Expiration date of 12/31/2029 and friendly name of Certrum Trusted ....
Note: An enterprise can also implement PKI for internal use. PKI can be used to authenticate employees who are accessing the network. In this case, the enterprise is its own CA.

The PKI Trust System

PKIs can form different topologies of trust. The simplest is the single-root PKI topology.
As shown in the figure below, a single CA, called the root CA, issues all the certificates to the end-users, which are usually within the same organization. The benefit of this approach is its simplicity. However, it is difficult to scale to a large environment because it requires a strictly centralized administration, which creates a single point of failure.
The figure shows a server labelled root c a with a certificate next to it. There are two arrows each pointing to a computer. each computer also has a certificate next to it.

Single-Root PKI Topology

On larger networks, PKI CAs may be linked using two basic architectures:
Cross-certified CA topologies – As shown in the figure below, this is a peer-to-peer model in which individual CAs establish trust relationships with other CAs by cross-certifying CA certificates. Users in either CA domain are also assured that they can trust each other.
This provides redundancy and eliminates the single point of failure.
The figure shows the same set up as the previous single-root PKI topology, but it is labelled c a 1. there is a two-way arrow between this topology and another of the same topology labelled c a 2. an arrow points from the c a 2 topology to another of the same topology labelled c a 3.

Cross-Certified CA

Hierarchical CA topologies – As shown in the figure below, the highest-level CA is called the root CA. It can issue certificates to end-users and to a subordinate CA. The sub-CAs could be created to support various business units, domains, or communities of trust.
The root CA maintains the established “community of trust” by ensuring that each entity in the hierarchy conforms to a minimum set of practices. The benefits of this topology include increased scalability and manageability. This topology works well in most large organizations. However, it can be difficult to determine the chain of the signing process.
A hierarchical and cross-certification topology can be combined to create a hybrid infrastructure. An example would be when two hierarchical communities want to cross-certify each other in order for members of each community to trust each other.
The figure shows a server labelled root c a with a certificate next to it. There are two arrows each pointing to a subordinate with a single-root pki topology.

Hierarchical CA

Interoperability of Different PKI Vendors

Interoperability between a PKI and its supporting services, such as Lightweight Directory Access Protocol (LDAP) and X.500 directories, is a concern because many CA vendors have proposed and implemented proprietary solutions instead of waiting for standards to develop.
Note: LDAP and X.500 are protocols that are used to query a directory service, such as Microsoft Active Directory, to verify a username and password.
To address this interoperability concern, the IETF published the Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework (RFC 2527). The X.509 version 3 (X.509 v3) standard defines the format of a digital certificate.

X.509v3 Applications

Certificate Enrollment, Authentication, and Revocation

The first step in the CA authentication procedure is to securely obtain a copy of the CA’s public key. All systems that leverage the PKI must have the CA’s public key, which is called the self-signed certificate. The CA public key verifies all the certificates issued by the CA and is vital for the proper operation of the PKI.
Note: Only a root CA can issue a self-signed certificate that is recognized or verified by other CAs within the PKI.
For many systems such as web browsers, the distribution of CA certificates is handled automatically. The web browser comes pre-installed with a set of public CA root certificates. Organizations and their website domains push their public certificates to website visitors. CAs and certificate domain registrars create and distribute private and public certificates to clients that purchase certificates.
The certificate enrollment process is used by a host system to enrol with a PKI. To do so, CA certificates are retrieved in-band over a network, and the authentication is done out-of-band (OOB) using the telephone. The system enrolling with the PKI contacts a CA to request and obtain a digital identity certificate for itself and to get the CA’s self-signed certificate.
The final stage verifies that the CA certificate was authentic and is performed using an out-of-band method such as the Plain Old Telephone System (POTS) to obtain the fingerprint of the valid CA identity certificate.
Authentication no longer requires the presence of the CA server, and each user exchanges their certificates containing public keys.
Certificates must sometimes be revoked. For example, a digital certificate can be revoked if a key is compromised or if it is no longer needed.
Here are two of the most common methods of revocation:
  • Certificate Revocation List (CRL) – A list of revoked certificate serial numbers that have been invalidated because they expired. PKI entities regularly poll the CRL repository to receive the current CRL.
  • Online Certificate Status Protocol (OCSP) – An internet protocol used to query an OCSP server for the revocation status of an X.509 digital certificate. Revocation information is immediately pushed to an online database.

 

Action Point
PS: If you would like to have an online course on any of the courses that you found on this blog, I will be glad to do that on an individual and corporate level, I will be very glad to do that I have trained several individuals and groups and they are doing well in their various fields of endeavour. Some of those that I have trained includes staffs of Dangote Refinery, FCMB, Zenith Bank, New Horizons Nigeria among others. Please come on Whatsapp and let’s talk about your training. You can reach me on Whatsapp HERE. Please note that I will be using Microsoft Team to facilitate the training.

I know you might agree with some of the points that I have raised in this article. You might not agree with some of the issues raised. Let me know your views about the topic discussed. We will appreciate it if you can drop your comment. Thanks in anticipation.

 

Fact Check Policy

CRMNAIJA is committed to fact-checking in a fair, transparent and non-partisan manner. Therefore, if you’ve found an error in any of our reports, be it factual, editorial, or an outdated post, please contact us to tell us about it.

 

Become Part Of our Fan Base on Facebook. Click Here.
Follow Us on Twitter. Click Here.
Many Crypto. One place. Use Roqqu

Hi, I now use RavenBank to send, receive and save money. I also pay my bills with ease, you should try it out too

Fact Check Policy
truehost
telegram
CRMNuggets Whatsapp Channel
About Adeniyi Salau 1500 Articles
Adeniyi Salau is a highly dedicated and committed Blogger of repute. He likes sharing his IT knowledge with others. My desire is to impact as many lives as possible with my IT skills. You can download my mobile APP. Download the ICTLOAD APP on Google Playstore. Thanks.

Be the first to comment

Leave a Reply

Your email address will not be published.


*