21.1 Client Certificates

only for RuBoard - do not distribute or recompile

A client certificate is a digital certificate designed to certify the identity of an individual. As with certificates for web sites, client certificates bind a particular name to a particular secret key. They are issued by certification authorities. Client certificates have many uses and benefits:

Digital certificates can eliminate the need to remember usernames and passwords. You simply sign your digital signature whenever you enter a restricted space (provided that the server accepts your digital signature).
Instead of deploying a large distributed database, organizations can simply use an authorization digital certificate issued by a particular CA as proof that the individual is authorized to access the resource. (Many organizations use the existence of a valid certificate from a CA as authorization in itself. This works, but it is costly because you then need a different CA for every service that you wish to be able to authorize separately.)
Because authenticating your identity with a digital certificate requires access to a secret key, it is harder for groups of individuals to share a single digital ID than it is for a group of people to share a username and password. This is because there are technical barriers to sharing secret keys between users, and because users may be unwilling to share a secret key that is used for more than one application. This is interesting to sites that have per-user charges for distributing information over the Internet.
Because digital certificates contain a person's public key, you can use somebody's digital certificate to send that person encrypted electronic mail.
Certificates that denote a person's age could be used for restrictions on sexually oriented material or on chat groups, provided that certificates are only issued to adults and that there's a way to prevent adults from sharing private keys with minors.
Certificates that denote a person's gender could be used to allow access to "women's only" or "men's only" spaces, provided, once again, that there are suitable controls on the issuance of certificates and the transfer of keys.

21.1.1 Why Client Certificates?

By creating strong systems for identifying users, certificates help eliminate anonymity. They do so even more effectively than cookies. A cookie merely leaves a track of where you have been through a web site. A digital certificate, on the other hand, leaves behind your name, email address, or other identifying information that by design can be traced back to you.

Because certificates eliminate anonymity, some Internet users are opposed to certificates on the grounds that they compromise a user's privacy. Well, of course they do: that's their purpose. As currently constructed, however, certificates are never sent by a web browser without the user's knowledge and permission. Furthermore, certificates never contain information that is unknown to the user. Of course, both of these conditions could change in the future.

In the long term, Internet users may change their minds about certificates. It's true that a mark of totalitarian regimes is the issuing of identification cards and strong penalties for the failure to produce those cards when asked. But identification cards also solidify a strong society and good behavior, giving authorities ways of holding people accountable for their actions (and reminding people they can be held accountable). They also permit trust and commerce, which benefit all members of society. Thus, strong identification is likely to become more common on the Internet. Digital signatures are likely to be a part of any identification infrastructure.

21.1.2 Support for Client-Side Digital Certificates

Client-side digital certificates are supported by Microsoft Internet Explorer 3.0 and above, Netscape Navigator 3.0 and above, and many other SSL-based applications. To support client-side certificates, a browser must provide the following functions:

Key creation: The browser contains code for creating a public/private key pair and sending the public key to a certification authority in the form of an HTTP POST transaction.
Certificate acquisition: The browser must be able to accept a certificate that is downloaded from the certification authority and to store the certificate in a certificate store.
Challenge/response: The browser must be able to use its stored secret key to sign a randomly generated challenge supplied by an SSL server.
Secure storage: The browser must have a secure place to store the secret key. Netscape Navigator allows keys to be stored in either an encrypted file or a cryptographic token, such as a smart card. Internet Explorer uses the Microsoft CryptoAPI, which allows for similar functionality. Figure 21-1 shows Netscape's functions.

Figure 21-1. Netscape's Personal Security Manager panel allows you to put a password on your secret keys and web site passwords. The password is used as an encryption key to encrypt your information. Netscape can automatically prompt you for the password the first time in a browsing session that the information is needed, each time, or after a set time of inactivity.

only for RuBoard - do not distribute or recompile