[Help] Last update at http://inet.nttam.com : Mon Aug 7 21:40:09 1995

Abstract -- Using Public Key Technology -- Issues of Binding and Protection Application Technology Track
A4: Security

[Previous] [Table [Next]
[Paper [Paper

Using Public Key Technology -- Issues of Binding and Protection

Galvin, James M. ( galvin@tis.com)
Murphy, Sandra L. ( murphy@tis.com)


Public key technology is well suited to providing digital signatures. Typically, the signature for an object is created by hashing the object with a one-way hash function and encrypting (signing) the hash value with the private key component of a public/private key pair. The signature is verified by decrypting it with the public key component to expose the hash value and comparing the exposed hash value to a recomputed hash value. If the two hash values match the signature is often considered valid. But is it?

From a mechanical point of view, the signature is valid. Given a data object, a signature object, and a public key it is possible to determine if the three elements are related. Specifically, at the conclusion of the calculation it will be known if the private key corresponding to the given public key was used to create the signature of the data object. From a user's point of view, however, the calculation only answers half the question.

At issue is the identity of the owner of the public/private key pair, i.e., the identity of the user claiming to control access to the private key component that was used to create the signature. In order to validate a signature a recipient must know the identity of the owner and the degree to which the owner protects the private key from disclosure. A signature is of little value when it is not known who created it since the significance of the data object can not be quantified without knowledge of its origin. Also, if an owner does not protect a private key from disclosure, then there is no way of knowing if it was really the owner who created the signature.

Within a small community of users, it is reasonable to assume that all users know the public keys of all other users and that all users know the degree to which all other users protect their private keys from disclosure. Individual users may construct their own quasi-small communities by contacting other users and exchanging public keys and other relevant information via various ad hoc and semi-formal mechanisms. This model has served and continues to serve a growing community of users concerned about the security of their communications. However, it falls very far short of being a solution for the global internet.

The global internet needs a mechanism with which users can acquire the public key of any other user and be able to quantify two things:

Quantifying these values is essential to developing application programs that can process data without explicit and direct user interaction, e.g., application programs that can process data in a batch mode. With this information, interactive user programs will be better able to support their users.

Users who do not determine whether the public key used to verify a signature is the correct public key are no better off than if the data object was not digitally signed. The reason is, there is nothing to prevent an interloper from substituting a public key for which the interloper controls the private key. Therefore, such an interloper could assert the identity of any owner.

To date, there has been very little examination of these subtle but very important issues. The OSI Directory community defined certificates (an embodiment of a binding between an owner's name and public key) in X.509 [1] but provided little guidance on how to use them effectively and how to protect the corresponding private key. In the Internet, Privacy Enhanced Mail (PEM) restricted the overly general rules of X.509 and specified a strict hierarchical organization for certificates, with enough rules to ensure that signatures and names could be evaluated programmatically [2]. PEM also included a discussion of some of the issues related to protecting the corresponding private keys. Pretty Good Privacy (PGP) [3] includes a mechanism that lends itself to individual users and conveniently supports the bottom-up construction of public key databases. It also includes a discussion of some of the issues related to protecting the corresponding private keys.

Each of these applications provides a similar mechanism for mechanically validating digital signatures, the first half of verifying a digital signature. However, each provides different guidance on the issue of validating the binding between the owner's name and the public key. None have any guidance for the recipients of signed data objects about evaluating the protection accorded private keys by their owners.

What the internet community needs is an examination of the issues associated with

With respect to binding identities to public keys, what exactly is an identity? In the case of the OSI Directory, an identity is represented by a distinguished name, an object which may convey quite a bit of information in addition to what would ordinarily be considered a user's name, e.g., perhaps an employer's name or a home address. In the case of PGP the name is a string of the user's choice. How is a user to interpret these values? How is user to know if the identify is accurate.

With respect to protecting private keys, since the cryptography is often done in software so are the keys stored in files on computer disks. The vulnerabilities of such a mechanism vary widely with the physical environment and the level of support provided by the host operating system. Alternatives, e.g., PCMCIA cards, do exist but are not suitable for everyone. How does a user decide what they need?

We propose to examine the issues and to suggest a criteria with which a user or a user's organization can determine what their requirements are and judge whether existing applications and protocols, and those currently under development, will meet their needs.


The Directory -- Authentication Framework. X.509, 1988. Developed in collaboration, and technically aligned, with ISO 9594-8.
Steve Kent. Privacy Enhancement for Internet Electronic Mail: Part II: Certification-Based Key Management. RFC 1422, BBN Communications, February 1993.
Will be reference to software documentation or RFC if available at time of publication.