![[Previous]](/HMP/GIF/inet-previous.gif)
![[Next]](/HMP/GIF/inet-next.gif)
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:
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 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.
REFERENCES