Digital Signatures

• The signature can only be created by someone who knows the secret information.
• Once a signature is created, anyone can validate that the signature is associated with the individual and the document, without needing to know the secret information used to create the digital signature.
• Since the signature depends on the document, it cannot be used to validate a different document.
• It is impossible to produce a document that differs from the original document by even a single bit but for which the signature is still valid.

There are now at least two common methods of generating digital signatures. One is a proprietary technology of RSA Data Security, Inc., and is called the RSA digital signature, after it's inventors Rivest, Shamir, and Adleman. This technology is being deployed in a large number of applications, and has been licensed by nearly every big telecommunications and computer company in the U.S, including AT&T, Apple, IBM, Microsoft, Novell, and Sun Microsystems. The only serious competitor to RSA signatures is that of the Digital Signature Algorithm (DSA), which was proposed by NIST as a Federal Information Processing Standard called the Digital Signature Standard (DSS) [7]. There is some controversy surrounding the licensing of DSA, since the holders of the RSA and other patents claim that DSA is covered by their patents. NIST has declared that ``The Department of Commerce is not aware of any patents that would be infringed by this standard'' [7]. In the next few years this point will become moot anyway, as many if not all of the relevant patents will expire by the year 2000 anyway.

RSA and DSA signatures use similar kinds of calculations, and these can be performed by a number hardware and/or software solutions. They rely upon the notion of a ``Key Certification Authority'' (CA) that is responsible for issuing and/or certifying keys. The primary role of a key certification authority is to provide assurance that a user's public key is accurate. The CA need not be online to answer questions about the legitimacy of keys. Instead, when a user is issued (or chooses and registers) their public/private key pair, the CA simply issues a digital signature of these keys to certify that these should be recognizable as having been issued to the particular user. These credentials generally have expiration dates and may convey other information such as a role for which the user is certified. When a digital signature is generated by a user, the credentials for the keys used to create the digital signature may be included with the digital signature (but this need not be the case). A user may obtain multiple credentials for their public key, and there is no need for the user to obtain multiple public/private key pairs for multiple applications. In particular, there should be no need that the public/private key pair of a user cannot be used for signing health documents as well as their email or their bank card transactions. For a user that accesses a system held by a given hospital, they may get credentials for their public key from the hospital itself. In order to access the system in the role of a nurse, they may want to present credentials for the same keys that were issued by an accreditation agency for nurses.

In addition to basic key certification through digital signatures under the certification authority's own public key, a key certification authority can provide:

• construction and issuance of private and public keys for users.
• recertification of keys whose certificates have expired.
• issuing key revocation lists for keys that have been compromised.

For a ``raw'' digital signature without certification credentials, we should expect the signature to only about 100-300 bytes, depending on the level of security chosen, but not depending on the size of the message. When a certificate chain is added to the signature, the credentials will grow to a size that is proportional to the length of the chain. It is therefore advantageous to set up key certification hierarchies that are not too deep.