Describe the 5 types of certificates and how they are used.
|
|
Types Of Certificates
There are five kinds of certificates:
-
Client SSL certificates
-
Server SSL certificates
-
S/MIME certificates
-
Object-signing certificates
-
CA certificates
Figure 2.11
We'll describe each of the five types, starting with SSL certificates.
SSL Protocol
The Secure Sockets Layer (SSL) protocol, which was originally
developed by Netscape, is a set of rules governing server authentication,
client authentication, and encrypted communication between servers and
clients. SSL is widely used on the Internet, especially for interactions
that involve exchanging confidential information such as credit card numbers.
Figure 2.12
SSL requires a server SSL certificate, at a minimum. As part of the
initial "handshake" process, the server presents its certificate to the
client to authenticate the server's identity. The authentication process
uses Public-Key Encryption and Digital Signatures to confirm
that the server is in fact the server it claims to be. Once the server
has been authenticated, the client and server use techniques of Symmetric-Key
Encryption, which is very fast, to encrypt all the information they
exchange for the remainder of the session and to detect any tampering that
may have occurred. Servers may optionally be configured to require client
authentication as well as server authentication. In this case, after server
authentication is successfully completed, the client must also present
its certificate to the server to authenticate the client's identity before
the encrypted SSL session can be established.
Signed and Encrypted Emails
Some email programs (including Messenger, which is part of
Communicator) support digitally signed and encrypted email using a widely
accepted protocol known as Secure Multipurpose Internet Mail Extension
(S/MIME). Using S/MIME to sign or encrypt email messages requires the sender
of the message to have an S/MIME certificate. An email message that includes
a digital signature provides some assurance that it was in fact sent by
the person whose name appears in the message header, thus providing authentication
of the sender. If the digital signature cannot be validated by the email
software on the receiving end, the user will be alerted.
The digital signature is unique to the message it accompanies. If the
message received differs in any way from the message that was sent - even
by the addition or deletion of a comma - the digital signature cannot be
validated. Therefore, signed email also provides some assurance that the
email has not been tampered with. Also, signed email makes it very difficult
for the sender to deny having sent the message. This is important for many
forms of business communication.
S/MIME also makes it possible to encrypt email messages. This is also
important for some business users. However, using encryption for email
requires careful planning. If the recipient of encrypted email messages
loses his or her private key and does not have access to a backup copy
of the key, for example, the encrypted messages can never be decrypted.
|
|
Single Sign-On
Network users are frequently required to remember multiple passwords
for the various services they use.
Figure 2.13
Both client SSL certificates and S/MIME certificates can play a significant
role in a comprehensive single sign-on solution. In addition to using
certificates, a complete single-sign on solution must address the need
to interoperate with enterprise systems, such as the underlying operating
system, that rely on passwords or other forms of authentication.
Form Signing
Many kinds of e-commerce require the ability to provide persistent
proof that someone has authorized a transaction. Although SSL provides
transient client authentication for the duration of an SSL connection,
it does not provide persistent authentication for transactions that may
occur during that connection. S/MIME provides persistent authentication
for email, but e-commerce often involves filling in a form on a web page
rather than sending an email.
The Netscape technology known as form signing addresses the need for
persistent authentication of financial transactions. Form signing allows
a user to associate a digital signature with web-based data generated as
the result of a transaction, such as a purchase order or other financial
document. The private key associated with either a client SSL certificate
or an S/MIME certificate may be used for this purpose.
When a user clicks the Submit button on a web-based form that supports form
signing, a dialog box appears that displays the exact text to be signed.
The form designer can either specify the certificate that should be
used or allow the user to select a certificate from among the client
SSL and S/MIME certificates that are installed in Communicator. When
the user clicks OK, the text is signed, and both the text and the digital
signature are submitted to the server. The server can then use a Netscape
utility called the Signature Verification Tool to validate the digital
signature.
Object Signing
Communicator and other Netscape products support a set of tools
and technologies called object signing. Object signing uses standard techniques
of public-key cryptography to let users get reliable information about
code they download in much the same way they can get reliable information
about shrink-wrapped software.
Most importantly, object signing helps users and network administrators
implement decisions about software distributed over intranets or the Internet--for
example, whether to allow Java applets signed by a given entity to use
specific computer capabilities on specific users' machines.
The "objects" signed with object signing technology can be applets or
other Java code, JavaScript scripts, plug-ins, or any kind of file. The
"signature" is a digital signature. Signed objects and their signatures
are typically stored in a special file called a JAR file.
Software developers and others who wish to sign files using object-signing
technology must first obtain an object-signing certificate.
|