PKI Entities

A PKI is the service framework needed to support large-scale public keybased technologies. The PKI is a set of all the technical, organizational, and legal components needed to establish a system that enables large-scale use of public key cryptography to provide authenticity, confidentiality, integrity, and nonrepudiation services.

Two very important terms need to be defined when talking about a PKI:

• A Certificate Authority (CA) is the trusted third party (trusted introducer) that signs the public keys of all end entities (PKI users).
• A certificate is a document that, in essence, binds the name of the entity and its public key that has been signed by the CA, so that every other entity will be able to trust it.

Note

Certificates are not secret information and do not need to be encrypted in any way. The idea is not to hide anything but to ensure the authenticity and integrity of the information contained in the certificate.

Another term that is often used with a PKI is certificate revocation list (CRL). The CRL is a list of certificates that should not be trusted anymore. Examples of when a certificate is added to the CRL ("revoked") include exposure or loss of the private key. A PKI user who receives a certificate should verify the CRL to ensure that the received certificate is not on the list of revoked certificates.

Many vendors offer CA servers as a managed service or as an end-user product:

• Microsoft Windows 2000/2003 Certificate Services (http://www.microsoft.com) is a Windows Server add-on that allows an organization to set up its own CA server.
• VeriSign (http://www.verisign.com) offers outsourced PKI services.
• Entrust Technologies (http://www.entrust.com) offers both PKI products and outsourcing services.
• The CA Proxy Function (CAPF) in Cisco CallManager can act as a standalone CA.

X.509v3 Certificates

X.509 is the ubiquitous and well-known standard that defines basic PKI data formats, such as certificate and CRL format, to enable basic interoperability. This format is already extensively used in the infrastructure of the Internet. X.509 is used for these applications:

• With secure web servers for website authentication in the Secure Sockets Layer (SSL) protocol
• With web browsers for services that implement client certificates in the SSL protocol
• With user mail agents that support mail protection using the Secure/Multipurpose Internet Mail Extensions (S/MIME) protocol
• In IPsec virtual private networks (VPNs) where certificates can be used as a public key distribution mechanism for Internet Key Exchange (IKE) Rivest, Shamir, and Adleman (RSA)based authentication

Figure 25-5 shows an example certificate format, following X.509 Version 3 (X.509v3). The most important pieces of information contained in the certificate are these:

• Subject X.500 Name (Name of the holder)
• Subject Public Key Information (Public key)
• CA Signature

Figure 25-5. Sample X.509 Certificate Format

Other fields include these:

• Certificate serial number
• Validity period of the certificate
• Signature Algorithms

Self-Signed Certificates

In a PKI system, all public keys are distributed in a form of a certificate, including the certificate of the trusted introducer, the CA. The obvious question is: Who signs the certificate of the CA, if it is itself the signer of all other certificates? In reality, the CA also issues a certificate to itself, just to have a consistent format for distributing its public key. This process is how the end entities obtain the public key of the CAby obtaining its self-signed certificate. The signature of a self-signed certificate of the CA cannot be verified using the standard method (verification by using the public key of the signer) because that public key should actually be protected by the signature. Therefore, other methods (such as manual verification) are needed to ensure the authenticity of a CA certificate.

Sometimes end entities also sign their own certificates. This happens if that particular end entity is not a part of a PKI but uses a PKI-enabled application. For example, a web server could generate a private and public RSA key and sign its public key with its private key to create a self-signed certificate. This certificate could then be used in Secure HTTP (HTTPS), where the web server would present a self-signed certificate to the connecting web browser. However, how does the web browser verify the presented certificate, if it was not issued (signed) by a known CA for which the web browser has a locally available certificate? This web server certificate, therefore, cannot be accepted automatically, but needs to be verified using some other method (such as the manual, out-of-band verification that is also used in pre-PKI protocols).

• Organizations will typically use self-signed certificates internally to save on the continual cost of obtaining certificates from a publicly known Certificate Authority (CA). This causes web browser clients to initially display warning messages when connecting to a server using a self-signed certificate.