7.1 PKI Protocols

Like any suite, PKI has a number of technologies that together create the PKI. Some of the most important protocols and standards you will examine when creating your own PKI are listed below. This list is not all-inclusive, but covers the technologies that are most related to PKI installations.

7.1.1 X.509

The process of certification is the most essential element of the entire PKI concept. Accordingly then, the X.509 certificate format is one of the most important standards associated with the PKI. X.509v2 and, more commonly, the X.509v3 certificate format are the most widely recognized certificate formats enabling the interoperation of PKIs on a global scale.

The X.509v3 certificate structure is outlined in Exhibit 6, along with a brief description of the relevant fields. Interested readers can also follow along using their own Web browsers. As mentioned, most commercial Web browsers include a number of certificates for root CAs that are used to verify the certificates of online merchants. Although the path to locate them will be different for each application, in Internet Explorer follow the path of Tools | Internet Options | Content | Certificates to find certificates locally stored on your PC. Odds are you will have to scroll to the right to find the root certificates. In Netscape or Mozilla, you may find the installed certificates by following the path of Edit | Preferences | Privacy & Security | Certificates | Manage Certificates. As with Internet Explorer, you may have to select the "Authorities" tab to view installed certificates. The version number in this case will be version 3; however, version 2 certificates are still found. As we will discuss shortly, version 3 has quickly become the accepted standard due to the use of optional extensions that allow certificate holders and signers to include important attributes with the certificate.

Exhibit 6: X.509v3 Certificate Format

Following the certificate number, a serial number is used to ensure that the certificate is unique for the certificate issuer. This serial number is assigned by the issuer. The algorithm, which should be familiar to those who have read the cryptography material of this text, is listed next.

The issuer field follows the signature algorithm. This must be a distinguished name (DN) for the certificate issuer. A distinguished name is a particular naming structure that is similar in operation to the domain name system (DNS). The major difference is that a DN naming structure is more flexible and has more layers of hierarchy than that used with DNS. As with domain names, there is a particular problem in a global infrastructure of ensuring that the name of any entity is globally unique. Using the DN convention from the X.500 standard with unique organizational identifiers assures this and also ensures that certificate signers can be uniquely identified.

Of particular interest is the validity date imprinted in the certificate. As the name suggests, this is the period of time for which the certificate is valid. Such a simple requirement causes no small complication in the management of certificates. The longer a certificate is valid the greater the chance that someone will be able to compromise the certificate by compromising the keys that were used to sign it. Configuring the validity period of the certificate to be too short adds administrative overhead to the PKI, as retired certificates must be replaced with valid ones. Just to gauge the difficulty of this task, imagine that the certificate you may be viewing in your Web browser were to expire. How would that certificate be replaced for the millions of users, most of them uneducated concerning certificates in the first place?

The subject field of the certificate follows the same DN format of the issuer, as described above.

The heart of a certificate, the part that makes it trustworthy, is the subject public key information in the certificate itself. This is the public key of the entity that the certificate is certifying. The entire point of this certificate and the PKI itself is to ensure users like ourselves that this public key really belongs to the organization in question. The organization that has signed the certificate is vouching for the authenticity of this key. This key will then be used to transmit a secret key between the remote host and the server, and it is the secret key that actually encrypts the data. In another scenario, the public key is the basis for authenticating the user and the certificate includes permissions of the user for the given application.

The issuer and subject ID fields are optional; they are not used in practice and are not recommended by the relevant RFCs for the Internet environment. ^[1]

In addition to the key itself, the extensions field is the portion of the certificate that makes X.509v3 relevant to modern PKIs. Both private extensions and optional standard extensions may be included in this field. This field enables the X.509v3 certificates to provide the necessary functions for a given application. Some common extensions include information that describes the permitted use of the certificate, information about revocation lists that may contain information about the certificate, and the ability to associate a certificate with more than a distinguished name, such as an e-mail address or other identifier.

While the X.509 standard does not specify the use of IP networks for certificate management functions, in most cases, IP is going to be the underlying network protocol responsible for communication between end entities and certification authorities in the PKI environment. To this end, the IETF (Internet Engineering Task Force) created the PKIX working group to define the required and optional extensions that may be found in X.509 certificates specific to the IP and IETF environment. The PKIX working group also defines the protocols that are used to manage certificates and perform other operational duties. The PKIX working group has been responsible for a number of RFCs that detail the different elements of IP/X.509 interaction. At the time of this writing, there were at least eight different RFCs with a number of the original eight already having been rendered obsolete and updated. Due to the work of the PKIX, the certificate format of X.509 has the ability to communicate among diverse portions of the Internet.

7.1.2 Lightweight Directory Access Protocol (LDAP)

The X.509 certificate format was based on work done for the ISO/ITU-T X.500 series. Together, the X.500 series defines a robust directory structure with a great deal of flexibility and power. The PKI and X.509 certificates were created to assist with access control to the X.500 directories. With this standard, however, came functionality and complexity that was not required in most implementations. In response to the need for a less complicated directory access protocol, the IETF created LDAP. LDAP devices are integral to a PKI in that they can contain both certificate information about directory subjects and include certificate revocation lists for the PKI.

7.1.3 Online Certificate Status Protocol (OSCP)

Critical to the functioning of a PKI is knowing that a certificate is valid, and just as important is knowing when a certificate should no longer be trusted. The OSCP is a straightforward protocol that queries a URL if provided in an extension to the X.509 certificate to check the certificate against a certificate revocation list (CRL), which is a list maintained by CAs to assist in the detection of revoked certificates. Likely responses from the CRL server are "good," "revoked," or "unknown."

Those with a suspicious mindset will immediately think, "How do I know that the CRL list that is being checked is valid?" After all, if someone were attempting to forge a certificate, why not point the certificate toward a CRL server that would respond that the CRL is valid? Fortunately, this has been considered as well, and OSCP responses from the servers use the same public key certificates that we use to ensure the trust of other Internet resources. However, it is useful to point out that OSCP does not determine if the certificate is valid or not. The certification and signing processes determine that. OSCP only determines if the certificate has been revoked — an important distinction!

7.1.4 Secure Multipurpose Internet Mail Extensions (S/MIME)

Due to the fact that SMTP was only developed to send plaintext e-mail, the Multipurpose Internet Mail Extensions (MIME) standards were proposed. MIME allows the encoding of a variety of information through the encoding of information in ASCII (plaintext) format. Based on the MIME specifications, RSA Security and other security vendors created S/MIME, which allows e-mail clients to encrypt mail using the MIME format. Due to industry acceptance of S/MIME, the specifications were adopted by the IETF into a series of RFCs detailing S/MIME's integration with IP, SMTP, and the PKI. Unlike IPSec, which encrypts the packets used to transfer e-mail, S/MIME encrypts the message itself. Therefore, when it is received, S/MIME messages need to be decrypted by the remote host.

S/MIME was constructed with an eye toward integration with the PKI. As such, S/MIME allows the use of certificates for both signing and encrypting e-mail, along with integration with certificate revocation lists and cryptographically signed return receipts.

The other program commonly used to encrypt e-mail and files is Pretty Good Privacy (PGP), created by Phil Zimmerman. PGP, as described in the trust models section above, utilizes a user-centric trust model. S/MIME, on the other hand, integrates with whatever trust model is being employed by the organization. Thus, S/MIME is suitable for both personal and business use. This, as well as the integration into an organizational PKI, makes S/MIME the more commonly found personal encryption client on corporate networks.

7.1.5 IP Security (IPSec)

Like the PKI, IPSec is a suite of enabling technologies that span a number of RFCs. Most commonly implemented in VPNs and other instances of secure communication exchange, a portion of IPSec responsible for the authentication and exchange of keys used in the creation of encrypted sessions can be configured to operate using the PKI. Known as Internet Key Exchange (IKE), this protocol is widely used in the establishment of all IPSec sessions. More information on IPSec and IKE can be found in the VPN section of this book (see Chapter 10).

7.1.6 Public Key Cryptography Standards (PKCS)

PKCS are a series of standards developed by RSA laboratories that define the operation of cryptographic operations with the PKI. Currently, there are 15 PKCS standards that cover some of the most common PKI operations. You will most likely run into these standards when you evaluate PKI solutions, as each vendor will note which PKCS they are compliant with. A brief listing of the standards can be found below. More information, along with the actual standards documents, can be found at the RSA Web site. ^[2]

PKCS #1: RSA Cryptography Standard. This is the original document that defines the implementation of public key cryptography using the RSA algorithm. PKCS #2 and #4 have been combined with PKCS #1.
PKCS #3: Defines the operation of the Diffie-Hellman algorithm, but you know how that works now.
PKCS #5: Password-Based Cryptography Standard. Defines key creation, encryption, and message authentication based on passwords.
PKCS #6: Extended certificate-Based Syntax. As our discussion of X.509v3 above describes, this standard defines the way in which an extendable certificate can be used to certify information in a certificate above and beyond the public key itself.
PKCS #7: Cryptographic Message Syntax Standard. Defines the application of cryptography to data such as digital signatures.
PKCS #8: Private Key Information Syntax Standard. Describes the syntax of private keys and their attributes.
PKCS #9: Attributes. This standard defines the acceptable attributes used with PKCS #6, #7, #8, and #10.
PKCS #10: Certification Request Syntax. Defines the proper way to ask for a certificate, distinguished name, and the associated attributes.
PKCS #11: Cryptographic Token Interface. Expands the use of PKI to provide an application interface for the integration of tokens.
PKCS #12: Personal Information Exchange Syntax. Defines acceptable methods of storing and transporting user private keys and certificates.
PKCS #13: Elliptical Curve Cryptography Standard. This is a standard still under development. It is widely believed that elliptical curves that are computed over a group of points defined by a solution to an elliptical curve algorithm will yield smaller keys that are equivalent in security to the larger keys more typically used. Elliptical curve algorithms are used more commonly with Diffie-Hellman algorithms and the future of this standard is uncertain.
PKCS #14: Pseudo-random Number Generation. Currently in development, this standard attempts to describe the process of creating suitably random numbers using binary processors. Although it may be surprising, most computers have a really difficult time coming up with truly random numbers. They may appear random to humans, but generally there is a pattern that can be detected if steps are not taken to generate truly random input as a seed for the random numbers. More than one security scheme has been broken by those who have figured out how the "random" numbers have been generated.
PKCS #15: Cryptographic Token Information Format. This standard expands upon PKCS #11 and attempts to ensure compatibility between all token devices and cryptographic applications. This type of compatibility will be essential if the ability to use a single "ID" card for multiple reasons will be realized.

7.1.7 Transport Layer Security (TLS)

Transport layer security is better known as the Secure Session Layer, or SSL. Introduced by Netscape Corporation with its browser product, SSL was instrumental in the success of secure Web browsing. Using encryption techniques much like IPSec does at the network layer, SSL creates encrypted application layer sessions between hosts. As with S/MIME, the success of the SSL protocol made it the de facto standard for encryption for both the transfer of Web pages, e-mail, and other applications. This success led to adoption by the IETF, which created the TLS specification from SSL. Reflecting their combined histories, this standard is often referred to as TLS/SSLv3.

The PKI is instrumental to the operation of TLS. To create an encrypted session to a Web server, the server sends the client a certificate signed by a CA to guarantee the authenticity of the server. The client encrypts a secret key to be used to establish a secure session with the Web server based on the public key part of the certificate. Encryption can take place without the certificate, but it is the certificate that provides the trust for the transaction to continue.

^[1]RFC 3280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile contains the relevant information regarding recommended X.509 fields in an Internet environment.

^[2]The PKCS standards can be found on the RSA Web site at http://www.rsasecurity.com.