Obtaining a Certificate

A certificate must be issued by a trusted authority, otherwise the people and organizations you do business with may not accept the ID. This is no different than a merchant accepting a name brand credit card. In addition, a name-brand certificate such as a Verisign ID is likely to be supported by most web browsers and servers.

Note that trust is transferred from “people trusting people” to people trusting an organization that is in the business of verifying a person’s credentials. This trust, along with public key cryptography, provides a system that supports safe electronic commerce and legal transactions.

Verisign has different classes of certificates. The higher the level, the greater the level of owner verification done by Verisign. Some sensitive web sites may only accept the highest-level certificates, for example. The classes are outlined below:

•  Class 1 certificates are personal IDs containing name and e-mail address only.

•  Class 2 certificates are personal IDs that require third-party verification of name, address, and other personal information submitted electronically by the applicant. Verification is done through the Equifax consumer database.

•  Class 3 certificates are personal IDs that require the owner to appear before a notary as well as submit personal information electronically.

•  Class 4 certificates are business IDs that provide all the features of Class 3 IDs as well as linking a user to a particular business or organization.

To obtain a digital certificate, you first generate a key pair on your own computer. Web browsers and some e-mail client software provide facilities for generating key pairs. You then submit the public key to a CA along with an electronic application to a CA. Once the CA verifies your credentials, it generates a certificate and returns it to you. You install it on your system and activate appropriate options in web browsers, e-mail programs, web servers, or other applications to indicate that you are ready to use digital certificates.

You can contact the following certificate authorities for more information:

Certificate Standards and Public Key Infrastructure (PKI)

Verisign represents one company that is involved in what will eventually become a global public key infrastructure (PKI). This infrastructure will include certification authorities around the world that can transfer trust among themselves. Such an infrastructure will promote international commerce and a person’s certificate will become a sort of global passport and a personal database that holds a wealth of information about you in a very secure way. For example, a certificate might include all the authorizations and access privileges for systems you need to access.

This global infrastructure requires internationally recognized standards. A universal digital certificate format is defined in the X.509 authentication-framework specification, which defines how to handle public keys via certificates. Specifically, X.509 defines a standard data structure for certificates, such as how user information is stored and how certifying authorities’ information is applied.

Digital Signatures

Digital signatures enable the recipient of a message to authenticate the sender of a message and verify that the message is intact as it was sent. A digitally signed message is something that must be done by the sender, so the recipient must request such a document. In a business or legal transaction, the sender may have no choice but to produce such a document in order to get the products or services they want.

Digitally signed and transmitted documents provide a new legal standard that goes beyond traditional signed documents. A handwritten signature is easy to counterfeit. In addition, the signer can repudiate the signature claiming it was counterfeited. Digital signatures have the advantage of being almost impossible to counterfeit. Also, proving that the document was signed by a person is easy by verifying the signature with that person’s public key.

Earlier, the following procedure was outlined for providing a level of message integrity:

1.  Encrypt the text with your private key.

2.  Send both the encrypted text and the normal text to the recipient.

3.  Recipient decrypts the encrypted text with your public key.

If the text can be decrypted with your public key, it must have come from you. The decrypted text can then be compared with the normal text to check its integrity.

This procedure is actually inefficient. A better way is to produce a fixed length signature from the plaintext message. This signature is produced by using a one-way function that converts a message of any length into a fixed-length message digest (hash). There are a number of hash functions available, including the Secure Hash Algorithm (SHA), which was developed by NIST (National Institute of Standards and Technology), and the MD series of message digest algorithms (MD2, MD4, and MD5) developed by Ron Rivest, cofounder of RSA Data Systems.

The reason for using hash functions rather than just encrypting the message as mentioned earlier is because hash functions are generally fast and the resulting digest are more secure. As mentioned previously, one-way functions are difficult if not impossible to revert.