|Previous||Table of Contents||Next|
A public-key certificate is someones public key, signed by a trustworthy person. Certificates are used to thwart attempts to substitute one key for another . Bobs certificate, in the public-key database, contains a lot more than his public key. It contains information about Bobhis name, address, and so onand it is signed by someone Alice trusts: Trent (usually known as a certification authority, or CA). By signing both the key and the information about Bob, Trent certifies that the information about Bob is correct and that the public key belongs to Bob. Alice checks Trents signature and then uses the public key, secure in the knowledge that it is Bobs and no one elses. Certificates play an important role in a number of public-key protocols such as PEM  (see Section 24.10) and X.509  (see Section 24.9).
A complicated noncryptographic issue surrounds this type of system. What is the meaning of certification? Or, to put it another way, who is trusted to issue certificates to whom? Anyone may sign anyone elses certificate, but there needs to be some way to filter out questionable certificates: for example, certificates for employees of one company signed by the CA of another company. Normally, a certification chain transfers trust: A single trusted entity certifies trusted agents, trusted agents certify company CAs, and company CAs certify their employees.
Here are some more things to think about:
Ideally, Bob would follow some kind of authentication procedure before the CA signs his certificate. Additionally, some kind of timestamp or an indication of the certificates validity period is important to guard against compromised keys .
Timestamping is not enough. Keys may be invalidated before they have expired, either through compromise or for administrative reasons. Hence, it is important the CA keep a list of invalid certificates, and for users to regularly check that list. This key revocation problem is still a difficult one to solve.
And one public-key/private-key pair is not enough. Certainly any good implementation of public-key cryptography needs separate keys for encryption and digital signatures. This separation allows for different security levels, expiration times, backup procedures, and so on. Someone might sign messages with a 2048-bit key stored on a smart card and good for twenty years, while they might use a 768-bit key stored in the computer and good for six months for encryption.
And a single pair of encryption and signature keys isnt enough, either. A private key authenticates a relationship as well as an identity, and people have more than one relationship. Alice might want to sign one document as Alice the individual, another as Alice, vice-president of Monolith, Inc., and a third as Alice, president of her community organization. Some of these keys are more valuable than others, so they can be better protected. Alice might have to store a backup of her work key with the companys security officer; she doesnt want the company to have a copy of the key she signed her mortgage with. Just as Alice has multiple physical keys in her pocket, she is going to have multiple cryptographic keys.
Distributed Key Management
In some situations, this sort of centralized key management will not work. Perhaps there is no CA whom Alice and Bob both trust. Perhaps Alice and Bob trust only their friends. Perhaps Alice and Bob trust no one.
Distributed key management, used in PGP (see Section 24.12), solves this problem with introducers. Introducers are other users of the system who sign their friends public keys. For example, when Bob generates his public key, he gives copies to his friends: Carol and Dave. They know Bob, so they each sign Bobs key and give Bob a copy of the signature. Now, when Bob presents his key to a stranger, Alice, he presents it with the signatures of these two introducers. If Alice also knows and trusts Carol, she has reason to believe that Bobs key is valid. If she knows and trusts Carol and Dave a little, she has reason to believe that Bobs key is valid. If she doesnt know either Carol or Dave, she has no reason to trust Bobs key.
Over time, Bob will collect many more introducers. If Alice and Bob travel in similar circles, the odds are good that Alice will know one of Bobs introducers. To prevent against Mallorys substituting one key for another, an introducer must be sure that Bobs key belongs to Bob before he signs it. Perhaps the introducer should require the key be given face-to-face or verified over the telephone.
The benefit of this mechanism is that there is no CA that everyone has to trust. The down side is that when Alice receives Bobs public key, she has no guarantee that she will know any of the introducers and therefore no guarantee that she will trust the validity of the key.
|Previous||Table of Contents||Next|