CCIE Study Notes

PKI is another vast topic that I'm going to have to use discernment with respect to what I discuss and what I leave out. There are books on the topic - and one of the best ones is from RSA Press : "PKI - Implementing and Managing E-Security." It's a bit dated - I read it back in 2003. But it formed a very solid base for my understanding of PKI. I will warn you - even I found it to be very dry, but essential.

PKI is Public Key Infrastructure - which is a framework for managing digital certificates and everything about them. Start with the idea of asymmetric encryption. It creates a public key and private key. You keep your private key secure and use it to sign and encrypt. Your public key verifies / decrypts something that only you could create. That "proves" it was you that signed/encrypted the item. But how do we know that any particular public key is really YOUR public key? Well, the way to do that is to get a CA to sign your public key, verifying that it's you. [This creates your digital signature - similar to a paper signature being verified by a Notary Public.] So how do we know that the CA from xyz.com is reliable and to be trusted to verify your signature? Well, you would need to trust that CA (like in the case where you are an employee of xyz.com). Now think of how this would scale if each computer/person had to personally know and trust each CA that signed digital certificates. Not very well, right? So we have a system where companies like (previously) Verisign or (currently) Symantec will sign a certificate (of your public key) for you at a price. They verify that you are who you say by having an account with them and paying a modestly large fee (around $1000). Then you can scale this hierarchically. You can trust Person B's public key because it is signed by the CA of xyz.com - which has a signature signed by Symantec (which is a company you trust). You can prove that you trust Symantec if you look in your computer's certificate store (you have to use the mmc to do this) and go to Trusted Root Certification Authorities | Certificates -- There it is! If you go there in a browser and click the lock, you can view certificates. This will show you the properties of the certificate and the Certification Path tab will show you the chain of signatures up to a root CA that you trust.

With that brief skim of PKI itself, let's look at the process in practice through an example. You generate your public and private key. Then you go to the web site of the CA. You download the CA's public certificate into your trusted certificate folder (so you trust the CA that is signing your public key). Make sure you also download the path to the root CA (if you have these in your trusted keys, skip this part). Fill out the Certificate Request form. You will have to know what you need the certificate to do (sign/encrypt, web/mail, etc) and all the information that you are trying to validate (your name, name of the server, etc). You submit the request and either it is automatically processed or your CA's server admin has to issue or reject the request. During this time your certificate is "Pending." Once processed, you go back to the site and download the signed certificate and install (use) it. That is one example. This example is based on a CSR (Certificate Signing Request) using a Microsoft CA. You can use a router as a CA. You can set things up for automatic approval of requests. You could request a certificate for a web server or to use secure mail...yadda, yadda, yadda. Like I said, this topic is big with many variations. But if you could follow along with all I've said and can visualize this in your mind (because you've done this before), then you should be good with anything they can come up with for PKI. [If not, get to know Alice and Bob and read that book.]

PKIX is the IETF Working Group that deals with the specifications of the X.509 Certificate. RFC 5280 covers X.509 Certificates and CRL Profile. To break this down to what's reasonable for this section and X.509 Certificates, you're going to want to know the Basic Certificate Fields (4.1 in the RFC). The basic list is:

* Version Number
* Serial Number
* Signature Algorithm Identifier
* Issuer Name
* Validity Period
* Subject Name
* Public Key Information
* Issuer Unique ID
* Subject Unique ID
* Extensions

To really bring this home, you should open a browser, go to a few of your favorite secured (https) sites (Google, Microsoft, etc) and view the certificates. Then use a few different browsers and see how the same certificate can be displayed differently by various browsers. Yes, all the same information is there, but displayed differently. After looking at them for a while, the fields will start to stick in your memory.

PKCS are the Public Key Cryptography Standards. These are standards developed by RSA. You might see something that says "PKCS#7 format" but that's just a way to refer to a message that is formatted in that standard way. The ones you should probably know are:

PKCS#7 - digital signatures and encryption

PKCS#10 - certification requests

PKCS#11 - Cryptoki - for cryptographic devices such as smart cards and PCMCIA cards

PKCS#12 - a portable format for storing or transporting a user's private keys, certificates, miscellaneous secrets, etc.

PKCS#13 - mechanisms for encrypting and signing data using Elliptic Curve Cryptography

Make sure you know that #12 is your private key, #10 is your request and #7 is what you're going to get back from your request. And with that, I'm putting this topic to bed. Some of the more detailed specifics will come up in the later sections.