In this lesson, we introduce the concepts of basic Public Key Infrastructure or abbreviated as PKI. We show its basic operation in signing the certificate requests and maintaining a certificate directory service and certificate revoke list. We will also show the CA hierarchy for dealing with large volume of certificate requests and different types of certificate requests. We concluded by comparing PKI with PTP we presented in previous lessons. In a public key infrastructure, short name for PKI, a user sends the certificate signing request, called CSR to the Certificate Authority (CA). Consider CA as en entity which signs certificate with how and where. So, where and also including the people who are operating with them. The CSI is written in X509 sender format. It includes a user's identity information in the subject name field. The Public Key, the signing message [INAUDIBLE] function to be used to generate the signature of the Digital Certificate. The CA verifies the identity used the proposed algorithms to sign the certificate. The certificate will include the identity of the subject, the issuer, which is the CA's identity, and the name of the signing and message digest function, the public key of the subject, and finally the signature. The CA saves a copy of the signed certificate in certificate directory for public retrieval and returns a copy back to the user. The user can send in a revocation password or request in case the private key is lost or the subject is no longer with user's organization. The CA will put the certificate in Certificate Revoke List. Any user can check if the certificate is still valid by consulting with the CRL list. To deal with volume of certificate requests, types of requests and the organization structure of the users, CA Hierarchy can be used to divide a test for different types of CA, at different levels. And dedicate the signing responsibility to them. At the top, is a self-signed CA called Root CA. It's a signed certificate for the intermediate CAs, and dedicates responsibility to them. Which in turn, sign and dedicate a few signing CA. The signing CA takes the end user's CA as our request, sign and returns the digital certificates. The end-user certificate can be issued for email, server authentication, client authentication, co-signing and email protection purposes. The end user certificate cannot be used to sign as a certificate. Here we show the certificate signing process. It is similar to the Bank of America service certificate signing and method signing, which we discussed in previous lessons. The user generates the CSR with public key and specific server or user identity information. The signing CA uses SHA 250 message digest functions to generate the hash and encrypt the signing CA's private key. The resulting sign hash, code signature is then appended to the end of the certificate. When the users receive the signed certificate, it installs it together with the related private key in the client web server, or secure applications such as secure email client. Here we show the certificates managed by Firefox, Browser's Certificate Manager. You can access it through the tool menu typically on the three bar icon on the rightmost of the toolbar. Select the advanced menu and the VU certificate button. Then the certificate manager window will appear. It shows the five different categories of certificates it maintains and manages. The authorities tab, which I'm showing right now, shows the certificate of the [INAUDIBLE] CA and intermediate CA and that divides into the specific company that provides CA services. It comes with a browser's distributions. We can also import a self-signed CA we trust. All belong to our organization into this certificate security store. Without this cell size CA, any server certificate signed by them will show with a warning triangle symbol with a bang. To allow the users, it may not be trustworthy. We can import our own kinds of certificate with private key to user certificate category. It allow us to mutually authenticate with a secure server. It can also be used by the free Thunderbird Email application to sign and encrypt emails. When the email program receives a signed email, it will verify it and check if they are signed by a legitimate CA in the authority category. The email certificate of the person will then be saved in people category. When sending future encrypted emails, the mail client needs the public key of the recipient in order to encrypt the message content. When the Firefox receives the legitimate server certificate, it also checks and saves them in server certificate category if it checks out okay. Here we discuss the similarity and difference between PKI and PGP. PKI the public key infrastructures is a framework for signing, distributing, revoking and accounting the public key certificates. It ensures secure user authentication, network traffic encryption, data integrity and non-repudiation. It uses CA to vet and bind public key to user ID. The drawback of PKI is that it requires longer registrations, longer verification and revoking process. It is centralized and, therefore, there is a potential vulnerability if the RCA fails. It costs more also to maintain. You have to pay for your server certificate to be signed, same as an email certificate. PGP, Pretty Good Privacy, for short, on the other hand, it's an application derived from the IETF open standard, open PGP. Like PKI you use public key cryptography and symmetric key cryptography, but I like PKI, use Web of Trust to vet and bind public key to user ID. It uses key server instead of CA as public key repositories. All the information publicly is distributed among many, many key servers. They're all under warranty. And, probably the most important, it is free.
