El proceso de socialización.

Public key certificates require a management infrastructure to support certificate gen- eration, distribution, and revocation. This infrastructure is called a public key infra- structure (PKI). Because certificate management is often tied to keys, PKIs often include the management of keys as well.

There are several components to a PKI. There is the CA, which we’ve discussed pre- viously. There can also be a registration authority (RA) and a directory. In addition to the software components, there is usually a certificate practices statement (CPS) that describes the operation of the PKI, its security measures, and the extent of the CA’s liability.

There are many ways that a PKI can operate. One PKI operational concept is shown in Figure 4.7.

1. Alice starts the process by generating a public key-private key pair.

2. Software on her system inserts her public key into a certificate request. She will usually sign the certificate request with her private key, the mate of the public key in the request.

3. The self-signed certificate is sent to an RA, since a self-signed request may not be sufficient proof of identity for a CA to issue a certificate.

4. Before the CA issues a certificate, Alice must convince the RA, a trusted opera- tive of the CA, that she is who she claims to be. The RA usually consists of a person and software used to create certificate requests. The RA’s most impor- tant function is to verify the identity of the presenter. For instance, if Alice is able to convince the RA that she is Sue and the RA requests a certificate for Sue with Alice’s public key, then Alice will be able to impersonate Sue.

5. Once Alice’s identity is verified, the RA takes Alice’s self-signed public key cer- tificate request and signs it. Alternatively, Alice can act as her own RA and sign the certificate request herself if the receiver of the signature is willing to accept the risk. Alice’s signature on the original request proves that she possesses the private key matching the public key in the request. Sometimes, to ensure that keys are properly generated, the key holder must create his or her key pair in the presence of the RA.

6. The RA sends the certificate request to the CA.

7. Upon receipt of the certificate request, the CA verifies the RA’s signature on the certificate request and verifies that the RA is entitled to make the request. Assuming that the RA is authorized, the CA takes the public key in the certifi- cate request, creates a public key certificate with it, and signs the certificate.

8. The certificate is returned to Alice, and she inserts it in a signed e-mail, with SSL, or wherever she needs her signature verified and the protocol in place per- mits it. Assuming that he trusts the CA, Bob, the recipient, can use the public key certificate to verify Alice’s signature.

9. The CA may also take the certificate and place it in a directory so that anyone wishing to communicate with Alice securely or wishing to verify her signature can retrieve her public key certificate independent of any direct communication with her.

If, for some reason, Alice’s keys are compromised because they’ve fallen into the wrong hands or her certificates are compromised because they have been inappropri- ately modified, the CA must be notified, and Alice’s certificate must be revoked. Once the CA is notified that the certificate is no longer valid, it places this certificate on its certificate revocation list (CRL) together with a date and time indicating when the cer- tificate ceased being valid. Transactions completed before this time are assumed to be good. Transactions after this time may be compromised. The CA generates this list periodically and posts it in a Lightweight Directory Access Protocol (LDAP) directory that holds certificate and CRLs in a tree-structured, hierarchical organization. Individ- uals or organizations wishing to communicate securely with a user in the hierarchy can retrieve the user’s certificate from the directory and verify the certificate’s validity by checking the CA’s CRL. In theory, anyone wishing to use Alice’s key should consult her CA’s CRL before using the key. In practice, since locating and then accessing the CA’s directory can be difficult (most applications that use public key cryptography do not support this feature), most certificate users do not do this, leaving open a potential security problem.

Figure 4.7 Public key infrastructure. Registration

Authority (RA) verifies identity (4) and signs certificate

request (5)

Alice Generates Key (1) and creates signed certificate request (2) Self-signed certificate Request (3) Certificate Authority (CA) creates public key

certificate (7) LDAP Certificate (8) Certificate (9) RA Signed Certificate Request (6) 84 Chapter 4

The original hope for PKIs was that there would a single, global, hierarchy of CAs. That way, the credibility of a CA could be validated, even if the recipient of a public key certificate did not formally know the specific CA. The reality is that most PKIs are inde- pendent of other PKIs. Cross-certification (one CA vouching for another CA) is some- times used when individuals in different PKIs must exchange information securely.