Certification Path | Public Key Infrastructure

If a public key user does not already hold a copy of the CA that signed the certificate including the CA’s name, then it might need an additional certificate to obtain that public key. A sample scenario appears in Figure 1. Let’s assume that Bob requested authentication from Alice with his certificate signed by CA1. But Alice, whose certificate was signed by CA2, does not have the public key for CA1, which is required to validate Bob’s certificate. Then, Alice forms a certificate chain that contains both CA2’s and her certificate and requests that CA1 provide a public key for CA1.

 
Figure 1: A Sample Certification Path

In general, a chain of multiple certificates might be needed that would make up a certificate containing the public key owner (the end entity) signed by one CA, and zero or more additional certificates originating from CAs signed by other CAs. Such chains, called certification paths, are required because a public key user is initialized with only a limited number of assured CA public keys. Certification path processing verifies the binding between the subject name and subject public key. This requires obtaining a sequence of certificates that support that binding.

Many organizations elect to create self-signed certificates for their public key infrastructure rather than purchase one or more from a Certificate Authority. In most cases, this is fine. However there are two differences between self-signed certificates and CA-signed certificates. SSL-enabled Web browsers normally recognize a CA-generated certificate and automatically allow a secure connection to be made, without prompting the user. Self-signed certificates usually generate an annoying (and sometimes to nontechnical users, frightening) pop-up. CAs also guarantee the identity of the organization that is providing services to the browser or other certificate-enabled device.

Before signing a certificate, a CA verifies the identity of the requesting organization. Thus, if your PKI is accessed by the public at large, you should provide a certificate signed by a CA so that people who visit or call know that your infrastructure is owned by the organization who claims to own it.

Basic Certificate Fields | Public Key Infrastructure

Basic certificate fields for X.509 version 3 are shown in Table 1. The To Be Signed (TBS) certificate field contains the names of the subject and issuer, a public key associated with the subject, a validity period, and other associated information. It usually includes extensions which hold additional optional information. The subject field identifies the entity associated with the public key stored in the subject public key field. It also distinguishes if a certificate is for an end entity, a CA, or a CRL. The Subject Public Key Info (SPKI) field is used to carry the public key and to identify the algorithm by which the key is used (e.g., RSA, DSA, or Diffie-Hellman).

Table 1: Basic Certificate Fields for X.509 

Certificate Fields	Attribute	Type
TBS Certif icate	Version	V1, v2, v3
	Certificate Serial Number	Integer
	Algorithm Id	Algorithm Object Id.
	Issuer	Name
	Validity	Not before time
		Not after time
	Subject	Name
	Subject Public Key Info	Algorithm Id
		Bit string
	Issuer Unique Id	Bit string
	Subject Unique Id	Bit string
	Extensions
Signature Algorithm		Algorithm Id
Signature Value		Bit string

The signature algorithm field contains the identifier for the cryptographic algorithm used by the CA to sign the certificate.

The signature value field contains a signature digitally added to the encoded TBS certificate. By generating this signature, a CA certifies the validity of the information in the TBS certificate. To be more specific, the CA certifies the binding between the public key material and the subject of the certificate.

Certificate Revocation List

When a certificate is issued, it is expected to be in use for its entire validity period. However, various circumstances may cause a certificate to become invalid prior to the expiration of the validity period. Such circumstances include change of name, change of association between subject and CA (e.g., an employee terminates employment with an organization), and compromise or suspected compromise of the corresponding private key. Under such circumstances, the CA needs to revoke the certificate.

CRL is similar to notices of stolen or lost credit cards reported to other credit companies. The CA periodically issues a signed data structure called a CRL. A CRL is a time-stamped list identifying revoked certificates. The list is signed by a CA or CRL issuer and made freely available in a public certificate and CRL repository. Each revoked certificate is identified in a CRL by its certificate serial number. When a system employing certificates uses a certificate for verifying a remote user’s digital signature, that system not only checks the certificate signature and validity, but also acquires a recent CRL and checks that the certificate serial number is not on that CRL.

Architectural Model and PKI Entities

Figure 1 shows a simplified view of the architectural model assumed by the PKI specification. This model is analogous to the credit card infrastructure. Even though the data is encrypted differently, the ways in which the entities in the two structures interact with each other are conceptually similar. Each PKI entity is like an entity in the credit card infrastructure.

 
Figure 1: PKI Entities and Their Relationships

We’ll now define the following PKI entities:

• End Entity User of PKI certificates and/or end-user system that is the subject of a certificate. Like a credit card reader in a retail store or restaurant, it reads a user certificate (credit card number) and queries the credit card company for the card holder’s legitimacy and credit limits.
• Certification Authority (CA) A system that issues PKI certificates. Think of credit card application processing, which checks an applicant’s credit history and issues a credit card.
• Registration Authority (RA) An optional system to which a CA delegates certain management functions.
• CRL issuer An optional system to which a CA delegates the publication of certificate revocation lists. This entity manages the equivalent of a stolen or lost credit card report and distributes certificate revocation information.
• Repository A system or collection of distributed systems that stores certificates and CRLs and that serves as a means of distributing these certificates and CRLs to end entities. An analogy would be a credit card holder database.

Operational protocols deliver certificates and CRLs (or status information) to client systems that use certificates. A variety of different ways to deliver certificates and CRLs are needed, including distribution procedures based on Lightweight Directory Access Protocol (LDAP), HTTP, File Transfer Protocol (FTP), and X.500.

Management protocols support online interactions between PKI user and management entities. For example, a management protocol might be used between a CA and a client system with which a key pair is associated, or between two CAs that cross-certify each other. The set of functions potentially needing to be supported by management protocols include user registration, client initialization, user certification, periodic key pair update, revocation request, and cross-certification.

Public Key Cryptography Concepts

Within the PKI framework, who you are is defined by the private keys you possess. From the point-of-view of PKI authentication authorities, you are your private key. In order to understand PKI, you will first have to understand some basic cryptological concepts. In Figure 1 the concept of a secret key is presented. Alice and Bob often are used as examples of the two parties engaged in a secure communications channel, and we will use them here. In this case, Alice and Bob both possess the same secret key. This can be a password, a token, or some other form of secret. Alice encrypts the plaintext that she wishes to send to Bob using her secret key. After Bob receives the ciphertext, he decrypts it using the same secret. The fact that the same key is used for both encryption and decryption determines that this is a symmetric exchange.

 
Figure 1: Symmetric Key Cryptography

PKI relies on a public/private key combination. The public and private keys are mathematical entities that are related. One key is used to encrypt information and only the related key can decrypt that same information; however, if you know one of the keys, it is computationally unfeasible to calculate the other. Your public key is something that you make public. It is freely distributed and can be accessed by everyone. A corresponding (and unique) private key is something that you keep secret. It is not shared with anyone. Your private key enables you to prove, unequivocally, that you are who you claim to be.

In Figure 2, Alice uses public key cryptography to send a ciphertext to Bob. She first locates Bob’s public key (normally from some type of directory service or from a previous secured document that Bob has sent to her) and encrypts the plaintext with Bob’s public key. She sends the encrypted text to Bob. Only Bob has the corresponding private key that can be used to decode the ciphertext.

 
Figure 2: Public Key Cryptography

Note that in normal practice, for performance reasons, the actual ciphertext is encrypted using a secret key algorithm as shown in Figure 1. Symmetric algorithms are much faster than public/private key algorithms (asymmetric cryptography). A random key (the session key) is generated, and it is used with the symmetric algorithm to encrypt the information. The public key is then used to encrypt that key and both are sent to the recipient. The private key is then used to decrypt the session key, and the resulting session key is used to decrypt the actual data.

The developers of public key cryptography were economical with keys. Both the public and private key are used for more than just encrypting and decrypting data or session keys. The private key also is used to digitally sign the sent message so that the sender’s identity is guaranteed. If the sender wishes to prove to a recipient that they are the source of the information (perhaps they accept legal responsibility for it), the sender uses his or her (or its) private key to digitally sign a message (a digital signature). Unlike a handwritten signature, a digital signature is different every time it is created. To create the digital signature, a hash of the message is signed (encrypted) with the sender’s private key The encrypted value either is attached to the end of the message or is sent as a separate file together with the message. The sender’s public key that corresponds to this private key may also be sent with the message, either on its own or as part of a certificate.

The receiver uses the sender’s public key to verify that the message hash calculated by the receiver (when certificates are used, the type of hashing algorithm will be included in the public key certificate sent with the message) is the same as the original hash. If the values match, the receiver is reasonably assured that the sender (the individual or device that owns the private key that corresponds with the public key) sent the information. The receiver also is reasonably assured that the information has not been altered since it was signed. This exchange forms the basis for two key security principles: nonrepudiation (the identity of the sender is verified) and message integrity (the contents of the message have not been altered in transit). Table 1 summarizes the intended use and owner of both public and private keys in public key cryptography.

Table 1: Key Usage in Public Key Cryptography 

Function	Key Type	Key Owner
Encrypt Data	Public Key	Bob (Receiver)
Sign Data	Private Key	Alice (Sender)
Decrypt Data	Private Key	Bob (Receiver)
Verify Data Integrity	Public Key	Alice (Sender)