Figure 2-29 shows an example of two entities communicating with a common CA, using digital certificates to validate public keys.
Figure 2-29: Digital Certificate Communication
Both routers and the CA have a public/private key pair. Initially, the CA has to enroll an X.509 v3 certificate for both routers in a secure manner. Also, both routers must receive a copy of the CA's public key in a secure manner. Now, if the router in New York has traffic to send to the router in Paris and wants authenticated, confidential delivery of the data, the following steps must occur:
Step 1 The New York router sends a request to the CA (for example, it makes an LDAP query) to obtain
the Paris router's public key.
Step 2 The CA sends the Paris router's certificate, signed with its own private key.
Step 3 The New York router verifies the signature with the CA's public key to validate the Paris router's
public key.
Step 4 The Paris router sends a request to the CA to obtain the New York router's public key. Step 5 The CA sends the New York router's certificate, signed with its own private key.
Step 6 The Paris router verifies the signature with the CA's public key to validate the New York router's
public key.
Now, both routers have each other's public key and can use public key encryption to send authenticated, confidential data.
Typically, an authenticated Diffie-Hellman exchange, as explained in Chapter 1, would take place to derive a shared key for secret key encryption because secret key encryption is usually used for bulk data encryption (it is much faster computationally).
Note The way certificates are exchanged can vary with implementations. For example, in IPsec, IKE
allows the certificate to be accessed independently (for example, through DNSSEC) or by having two devices explicitly exchange certificates as part of IKE.
Certificates
Users of public key-based systems must be confident that, any time they rely on a public key, the
associated private key is owned by the subject with which they are communicating. (This applies whether an encryption or digital signature mechanism is used.) This confidence is obtained through the use of
public key certificates, which are data structures that bind public key values to subjects. The binding is
achieved by having a trusted CA verify the subject's identity and digitally sign each certificate. The purpose of a CA, therefore, is to bind a public key to the common name of the certificate and, thus, assure third parties that some measure of care has been taken to ensure that this binding is valid.
The CA paradigm essentially relies on an authentication chain that ends in a CA that eventually certifies itself. The problem is shifted from a local perspective to a global perspective, with the whole chain depending on one final link.
A certificate has a limited valid lifetime, indicated in its signed contents. Because a certificate's signature and timeliness can be independently checked by a certificate-using client, certificates can be distributed using untrusted communications and server systems and can be cached in unsecured storage in
certificate-using systems.
Certificates are used in the process of validating signed data. Specifics vary according to which algorithm is used, but the general process works as follows:
1. The recipient of signed data verifies that the claimed identity of the user is in accordance with the identity contained in the certificate.
2. The recipient validates that no certificate in the path has been revoked (for example, by
retrieving a suitably current CRL or querying an online certificate status responder), and that all certificates were within their validity periods at the time the data was signed.
3. The recipient verifies that the data does not claim to have any attributes for which the certificate indicates that the signer is not authorized.
4. The recipient verifies that the data has not been altered since it was signed by using the public key in the certificate.
If all of these checks pass, the recipient can accept that the data was signed by the purported signer. The process for keys used for encryption is similar to the preceding process.
NOTE It can, of course, be possible that data was signed by someone very different from the signer (for example, if the purported signer's private key was compromised). Security depends on all parts of the certificate-using system, including but not limited to, the following:
· The physical security of the place in which the computer resides
system)
· The security provided by the operating system on which the private key is used · The security provided the CA
A failure in any one of these areas can cause the entire security system to fail.
The X.509 Standard
The X.509 standard constitutes a widely accepted basis for a PKI infrastructure, defining data formats and procedures related to the distribution of public keys using certificates digitally signed by CAs. RFC 1422 specified the basis of an X.509-based PKI, targeted primarily at satisfying the needs of Internet privacy-enhanced mail (PEM). Since RFC 1422 was issued, application requirements for an Internet PKI have broadened tremendously, and the capabilities of X.509 have greatly advanced. Much work is being done to use digital certificates in Web, email, and IPsec applications. The current standards define the X.509 Version 3 certificate and Version 2 CRL.
X.509 V3 Certificate
The information contained in the certificate must be uniform throughout the PKI. The current proposed standard to provide a common baseline for the Internet uses a X.509 V3 certificate format (see Figure 2-30).
Figure 2-30: The X.509 V3 Certificate Format
Every certificate contains three main fields: The body of the certificate
●
The signature algorithm ●
The signature itself ●
The body of the certificate contains the version number, the serial number, the names of the issuer and subject, a public key associated with the subject, and an expiration date (not before and not after a specified time/date); some certificate bodies contain extensions, which are optional unique identifier fields that associate additional attributes with users or public keys. The signature algorithm is the
algorithm used by the CA to sign the certificate. The signature is created by applying the certificate body as input to a one-way hash function. The output value is encrypted with the CA's private key to form the signature value, as shown in Figure 2-31.
Figure 2-31: Creating a Digital Signature for an X.509 V3 Certificate
X.509 V2 CRL
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 before the validity period expires. Such
circumstances might include a change of name, a change of association between the subject and CA (for example, an employee terminates employment with an organization), and the compromise or suspected compromise of the corresponding private key. Under such circumstances, the CA should revoke the certificate.
X.509 defines one method of certificate revocation. This method requires each CA to periodically issue a signed data structure called a certificate revocation list (CRL). A CRL is a timestamped list that identifies revoked certificates. The CRL is signed by a CA and made freely available in a public repository. Each revoked certificate is identified in a CRL by its certificate serial number. When a certificate-using system uses a certificate (for example, to verify a remote user's digital signature), that system not only checks the certificate signature and validity but also acquires a suitably recent CRL and checks that the certificate serial number is not on that CRL.
The meaning of "suitably recent" can vary with local policy, but it usually means the most recently issued CRL. A CA issues a new CRL on a regular basis (hourly, daily, or weekly). CAs may also issue CRLs at unpredictable time intervals (for example, if an important key is deemed compromised, the CA may issue a new CRL to expedite notification of that fact, even if the next CRL does not have to be issued for some time).
Note A problem of unpredictable CRL issuance is that end-entities may not know that a new CRL has
been issued and, thus, may not retrieve it from a repository.
An entry is added to the CRL as part of the next update following notification of revocation. An entry can be removed from the CRL after it appears on one regularly scheduled CRL issued beyond the revoked certificate's validity period.
An advantage of the CRL revocation method is that CRLs can be distributed in exactly the same way as certificates themselves: using untrusted communications and server systems.
One limitation of the CRL revocation method, using untrusted communications and servers, is that the time granularity of revocation is limited to the CRL issue period. For example, if a revocation is reported now, that revocation will not be reliably notified to certificate-using systems until the next CRL is
issued---which may be up to one hour, one day, or one week, depending on the frequency at which the CA issues CRLs.