【正文】 ondent is A. Thus, a total of seven messages are required. However, the initial four messages need be used only infrequently because both A and B can save the other39。s public key for future use, a technique known as caching. Periodically, a user should request fresh copies of the public keys of its correspondents to ensure currency. PublicKey Certificates The scenario of Figure is attractive, yet it has some drawbacks. The publickey authority could be somewhat of a bottleneck in the system, for a user must appeal to the authority for a public key for every other user that it wishes to contact. As before, the directory of names and public keys maintained by the authority is vulnerable to tampering. An alternative approach, first suggested by Kohnfelder [KOHN78], is to use certificates that can be used by participants to exchange keys without contacting a publickey authority, in a way that is as reliable as if the keys were obtained directly from a publickey authority. In essence, a certificate consists of a public key plus an identifier of the key owner, with the whole block signed by a trusted third party. Typically, the third party is a certificate authority, such as a government agency or a financial institution, that is trusted by the user munity. A user can present his or her public key to the authority in a secure manner, and obtain a certificate. The user can then publish the certificate. Anyone needed this user39。s public key can obtain the certificate and verify that it is valid by way of the attached trusted signature. A participant can also convey its key information to another by transmitting its certificate. Other participants can verify that the certificate was created by the authority. We can place the following requirements on this scheme: 1. Any participant can read a certificate to determine the name and public key of the certificate39。s owner. 2. Any participant can verify that the certificate originated from the certificate authority and is not counterfeit. 3. Only the certificate authority can create and update certificates. These requirements are satisfied by the original proposal in [KOHN78]. Denning [DENN83] added the following additional requirement: 4. Any participant can verify the currency of the certificate. A certificate scheme is illustrated in Figure . Each participant applies to the certificate authority, supplying a public key and requesting a certificate. Figure . Exchange of PublicKey Certificates Application must be in person or by some form of secure authenticated munication. For participant A, the authority provides a certificate of the form CA = E(PRauth, [T||IDA||PUa]) where PRauth is the private key used by the authority and T is a timestamp. A may then pass this certificate on to any other participant, who reads and verifies the certificate as follows: D(PUauth, CA) = D(PUauth, E(PRauth, [T||IDA||PUa])) = (T||IDA||PUa) The recipient uses the authority39。s public key, PUauth to decrypt the certificate. Because the certificate is readable only using the authority39。s public key, this verifies that the certificate came from the certificate authority. The elements IDA and PUa provide the recipient with the name and public key of the certificate39。s holder. The timestamp T validates the currency of the certificate. The timestamp counters the following scenario. A39。s private key is learned by an adversary. A generates a new private/public key pair and applies to the certificate authority for a new certificate. Meanwhile, the adversary replays the old certificate to B. If B then encrypts messages using the promised old public key, the adversary can read those messages. In this context, the promise of a private key is parable to the loss of a credit card. The owner cancels the credit card number but is at risk until all possible municants are aware that the old credit card is obsolete. Thus, the timestamp serves as something like an expiration date. If a certificate is sufficiently old, it is assumed to be expired. One scheme has bee universally accepted for formatting publickey certificates: the standard. certificates are used in most work security applications, including IP security, secure sockets layer (SSL), secure electronic transactions (SET), and S/MIME, all of which are discussed in Part Two. is examined in detail in Chapter 14. Distribution of Secret Keys Using PublicKey Cryptography Once public keys have been distributed or have bee accessible, secure munication that thwarts eavesdropping (Figure ), tampering (Figure ), or both (Figure ) is possible. However, few users will wish to make exclusive use of publickey encryption for munication because of the relatively slow data rates that can be achieved. Accordingly, publickey encryption provides for the distribution of secret keys to be used for conventional encryption. Simple Secret Key Distribution An extremely simple scheme was put forward by Merkle [MERK79], as illustrated in Figure . If A wishes to municate with B, the following procedure is employed: 1. A generates a public/private key pair {PUa, PRa} and transmits a message to B consisting of PUa and an identifier of A, IDA. 2. B generates a secret key, Ks, and transmits it to A, encrypted with A39。s public key. 3. A putes D(PRa, E(PUa, Ks)) to recover the secret key. Because only A can decrypt the message, only A and B will know the identity of Ks. 4. A discards PUa and PRa and B discards PUa. Figure . Simple Use of PublicKey Encryption to Establish a Session Key A and B can now securely municate using conventional encryption and the session key Ks. At the pletion of the exchange, both A and B discard Ks. Despite its simplicity, this is an attractive protocol. No keys exist before the start of the munication and none exist after the pletion of munication. Thus, the