S/MIME
Secure/Multipurpose Internet Mail Extension (S/MIME)
is a security enhancement
to the MIME Internet e-mail
format standard based
on technology from RSA Data Security. Although both PGP and S/MIME are
on an IETF standards track, it appears
likely that S/MIME
will emerge as the industry standard for commercial and organizational use, while PGP will remain
the choice for personal e-mail
security for many users. S/MIME
is defined in a number
of documents—most importantly RFCs 3370, 3850,
3851, and 3852.
To understand S/MIME, we need first to have a general
understanding of the underlying e-mail
format that it uses, namely MIME.
But to understand the signifi- cance of MIME, we need to go back to the traditional e-mail format standard,
RFC 822, which is still in common use. The most recent
version of this format specifica- tion is RFC 5322 (Internet
Message Format). Accordingly, this section first
provides an introduction to these two earlier standards and then moves
on to a discussion of S/MIME.
RFC 5322
RFC 5322 defines
a format for text messages that are sent using electronic mail. It has been
the standard for Internet-based text mail messages and remains
in common use. In
the RFC 5322 context, messages are viewed
as having an envelope and contents.The envelope contains
whatever information is needed to accomplish transmission and delivery. The contents compose the object to be delivered to the recipient. The RFC
5322 standard applies only to the contents.
However, the content standard
includes a set of header fields that may be used by the mail system to create
the envelope, and the
standard is intended to facilitate the acquisition of such information by programs.
The overall structure
of a message that conforms
to RFC 5322 is very simple.
A message consists of some number of header lines
(the header) followed by unre-
stricted text (the body). The header is separated from the body by a
blank line. Put differently, a message is ASCII text, and all lines
up to the first blank line are assumed to be header lines
used by the user agent
part of the mail system.
A header line usually consists
of a keyword, followed by a colon,
followed by the keyword’s
arguments; the format allows a long line to be broken up into several lines. The most
frequently used keywords are From,
To, Subject, and Date.
Here is an example message:
Date: October 8, 2009 2:15:49 PM EDT
From: "William
Stallings"<ws@shore.net>
Subject: The Syntax in RFC 5322 To:
Smith@Other-host.com
Cc: Jones@Yet-Another-Host.com
Hello. This section begins the actual message
body, which is delimited from the message heading by a blank line.
Another field that is commonly found in RFC 5322 headers
is Message-ID. This field contains a
unique identifier associated with this message.
Multipurpose Internet Mail Extensions
Multipurpose Internet Mail Extension (MIME)
is an extension to the RFC 5322 framework that is intended to address some of the
problems and limitations of the use of Simple Mail Transfer Protocol (SMTP), defined in RFC 821, or some other mail transfer
protocol and RFC 5322 for electronic mail.
[PARZ06] lists the follow- ing limitations of the
SMTP/5322 scheme.
1.
SMTP cannot transmit
executable files or other binary objects. A number of schemes are in use for converting binary files into a text form that can be used
by SMTP mail systems, including the popular UNIX UUencode/UUdecode scheme. However,
none of these
is a standard or even a de facto
standard.
2.
SMTP cannot transmit
text data that includes national language characters, because these are
represented by 8-bit codes with values of 128 decimal or higher,
and SMTP is limited to 7-bit
ASCII.
3.
SMTP servers may reject mail message over a certain size.
4.
SMTP gateways that translate between ASCII and the character code EBCDIC
do not use a consistent set of mappings, resulting in translation problems.
5.
SMTP gateways
to X.400 electronic mail networks cannot handle nontextual data included
in X.400 messages.
6.
Some SMTP implementations do not adhere
completely to the SMTP standards
defined in RFC
821. Common problems include:
•
Deletion, addition, or reordering of carriage return and linefeed
•
Truncating or wrapping lines longer than 76 characters
•
Removal of trailing white
space (tab and space characters)
•
Padding of lines in a message
to the same length
•
Conversion of tab characters into multiple space
characters
MIME is intended to resolve these problems
in a manner that is compatible with existing RFC 5322 implementations. The
specification is provided in RFCs 2045
through 2049.
OVERVIEW The
MIME specification includes the following elements.
1.
Five new message header fields are defined, which
may be included in an RFC
5322 header. These fields provide
information about the body of the message.
2.
A number of content
formats are defined, thus standardizing representations that support
multimedia electronic mail.
3.
Transfer encodings are defined
that enable the conversion of any content
for- mat into a form that is protected
from alteration by the mail system.
In this subsection, we introduce the five
message header fields. The next two subsections deal with content formats and
transfer encodings.
The five header fields defined in MIME are
•
MIME-Version: Must have the parameter value
1.0. This field
indicates that the message
conforms to RFCs 2045 and 2046.
•
Content-Type: Describes the data contained in the body with sufficient detail that the receiving user agent can pick an appropriate
agent or mechanism to represent the data to the user or otherwise deal with the
data in an appropri- ate manner.
•
Content-Transfer-Encoding: Indicates the
type of transformation that has been used to represent
the body of the message
in a way that is acceptable for mail
transport.
•
Content-ID: Used to identify MIME entities uniquely in multiple contexts.
•
Content-Description: A
text description of the object with the body; this is useful when the object
is not readable (e.g., audio data).
Any or all
of these fields
may appear in a normal
RFC 5322 header. A compliant
implementation must support the MIME-Version, Content-Type, and Content- Transfer-Encoding fields; the Content-ID and Content-Description fields
are optional and may be ignored
by the recipient implementation.
MIME CONTENT TYPES The bulk of the MIME specification is concerned with the
definition of a variety of content types. This reflects the need to
provide standardized ways of dealing
with a wide variety of information representations in a multimedia environment.
Table 18.3 lists the content
types specified in RFC 2046. There are
seven different major types of content and a total of 15 subtypes. In general,
a content type declares
the general
type of data, and the subtype specifies a particular format for that type of data.
For the text type of
body, no special software is required to get the
full meaning of the text aside
from support of the indicated character set. The primary
subtype is plain text, which
is simply a string of ASCII characters or ISO 8859 characters. The enriched
subtype allows greater
formatting flexibility.
The multipart
type indicates
that the body
contains multiple, independent parts. The Content-Type header field includes
a parameter (called
a boundary) that defines the delimiter between body parts.
This boundary should not appear in any parts
of the message. Each boundary starts on a new line and consists
of two hyphens followed by the
boundary value. The final boundary,
which indicates the end of the last part, also has a suffix of two hyphens. Within
each part, there may be an optional ordinary MIME header.
Table
18.3 MIME
Content Types
Here is a simple example of a multipart
message containing two parts—both consisting of simple text (taken from RFC
2046).
From: Nathaniel Borenstein <nsb@bellcore.com> To: Ned Freed <ned@innosoft.com>
Subject: Sample message MIME-Version: 1.0
Content-type: multipart/mixed; boundary="simple boundary"
This is the preamble. It is to be ignored,
though it is a handy place for mail composers to
include an explanatory note to non-MIME conformant readers.
—simple
boundary
This is implicitly typed plain ASCII text. It
does NOT end with a linebreak.
—simple
boundary
Content-type: text/plain; charset=us-ascii
This is explicitly typed plain ASCII text. It
DOES end with a linebreak.
—simple
boundary—
This is the epilogue. It is also to be
ignored.
There are four subtypes of the multipart type, all of which have the same over-
all syntax. The multipart/mixed subtype
is used when there are multiple
indepen- dent body parts that need to
be bundled in a particular order. For the multipart/parallel subtype, the order
of the parts
is not significant. If the recipient’s system is appropriate, the multiple parts can be presented in parallel. For example,
a picture or text part could be accompanied by a voice commentary that
is played while the picture
or text is displayed.
For the multipart/alternative subtype, the various
parts are different represen- tations of the same information. The following
is an example:
From: Nathaniel Borenstein <nsb@bellcore.com> To: Ned Freed <ned@innosoft.com>
Subject: Formatted text mail MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary=boundary42
—boundary42
Content-Type: text/plain; charset=us-ascii
...plain text version of message goes here....
—boundary42
Content-Type: text/enriched
.... RFC 1896 text/enriched version of same
message goes here ...
—boundary42—
In this subtype, the body parts are ordered in terms of
increasing preference. For this example, if the recipient
system is capable
of displaying the message in the
text/enriched format, this is done;
otherwise, the plain
text format is used.
The multipart/digest
subtype is used when each of the body parts is inter- preted as an RFC 5322 message
with headers. This
subtype enables the construction
of a message whose parts
are individual messages. For example,
the moderator of a
group might collect e-mail messages
from participants, bundle
these messages, and send
them out in one encapsulating MIME message.
The message type provides a number
of important capabilities in MIME. The message/rfc822
subtype indicates that the body is
an entire message, including header and body. Despite the name of this subtype, the encapsulated message may be
not only a simple RFC 5322 message
but also any MIME message.
The message/partial subtype enables fragmentation of a large
message into a number of parts, which must be
reassembled at the destination. For this
subtype, three parameters are specified in the Content-Type: Message/Partial
field: an id common to all fragments
of the same message, a sequence number unique
to each fragment, and the total number of fragments.
The message/external-body subtype
indicates that the actual
data to be con-
veyed in this message are not contained in the body. Instead,
the body contains
the information needed to access the data. As with the other message
types, the mes- sage/external-body subtype has an outer
header and an encapsulated message
with its own header. The only necessary field in the outer header is the
Content-Type field, which identifies this as a message/external-body subtype.
The inner header is the message header for the encapsulated
message. The Content-Type field in the outer
header must include
an access-type parameter, which indicates the method of access, such as FTP (file transfer
protocol).
The application type refers to other kinds of data, typically either uninter-
preted binary data or information to be processed by a mail-based application.
MIME TRANSFER ENCODINGS The other major component of the MIME specification, in
addition to content type specification, is a definition of transfer encodings
for message bodies. The objective is to provide reliable delivery across the
largest range of environments.
The MIME
standard defines two methods of
encoding data. The Content- Transfer-Encoding field can actually
take on six values, as listed in
Table 18.4. However, three
of these values (7bit, 8bit,
and binary) indicate
that no encoding has been done
but provide some information about the nature of the data. For SMTP transfer, it is safe to use the
7bit form. The 8bit and binary forms
may be usable in other mail transport contexts. Another
Content-Transfer-Encoding value
is x-token,
which indicates that some other encoding scheme is used for which a name is to be supplied. This could be a vendor-specific or application-specific scheme.
The two actual
encoding schemes defined are quoted-printable and base64. Two schemes are defined to provide a choice between
a transfer technique that is essentially human readable and one that is
safe for all types of data in a way that is reasonably compact. The quoted-printable
transfer encoding is useful when the data consists largely
of octets that correspond to printable ASCII characters. In essence,
it represents nonsafe characters by the hexadecimal representation of their
code and
introduces reversible (soft) line breaks to
limit message lines to 76 characters.
The base64
transfer encoding, also known
as radix-64 encoding, is a common one for encoding arbitrary binary
data in such a way as to be invulnerable to the processing by mail-transport
programs. It is also used in PGP and is described in Appendix 18A.
A MULTIPART
EXAMPLE Figure 18.8, taken from RFC 2045,
is the
outline of a complex multipart message. The message has five parts
to be displayed serially: two introductory plain text parts,
an embedded multipart
message, a richtext
part, and a closing encapsulated text message in a
non-ASCII character set. The embedded multipart message has two parts to be
displayed in parallel: a picture and an audio fragment.
CANONICAL FORM An important concept in
MIME and S/MIME is that of canonical form. Canonical form is a format, appropriate to the content
type, that is standardized for use between
systems. This is in contrast
to native form, which is a
format that may be peculiar to a particular system. Table 18.5,
from RFC 2049, should help clarify this matter.
S/MIME Functionality
In terms of general functionality, S/MIME is
very similar to PGP. Both offer the ability to sign and/or encrypt messages.
In this subsection, we briefly summarize S/MIME capability. We then look
in more detail
at this capability by examining mes- sage formats and message
preparation.
MIME-Version: 1.0
From: Nathaniel Borenstein <nsb@bellcore.com> To: Ned Freed <ned@innosoft.com>
Subject: A multipart example Content-Type: multipart/mixed;
boundary=unique-boundary-1
This is the preamble area of a multipart message. Mail readers that understand multipart format should ignore this preamble. If you are reading this text, you might want to consider changing to a mail reader that understands how to properly display multipart messages.
--unique-boundary-1
...Some text appears here...
[Note that the preceding blank line means no header fields were given and this is text, with charset US ASCII. It could have been done with explicit typing as in the next part.]
--unique-boundary-1
Content-type: text/plain; charset=US-ASCII
This could have been part of the previous part, but illustrates explicit versus implicit typing of body parts.
--unique-boundary-1
Content-Type: multipart/parallel; boundary=unique-boundary-2
--unique-boundary-2 Content-Type: audio/basic
Content-Transfer-Encoding: base64
... base64-encoded 8000 Hz single-channel mu-law-format audio data goes here....
--unique-boundary-2 Content-Type: image/jpeg
Content-Transfer-Encoding: base64
... base64-encoded image data goes here....
--unique-boundary-2--
--unique-boundary-1 Content-type: text/enriched
This is <bold><italic>richtext.</italic></bold> <smaller>as defined in RFC 1896</smaller> Isn't it <bigger><bigger>cool?</bigger></bigger>
--unique-boundary-1
Content-Type: message/rfc822
From: (mailbox in US-ASCII) To: (address in US-ASCII) Subject: (subject in US-ASCII)
Content-Type: Text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: Quoted-printable
... Additional text in ISO-8859-1 goes here ...
--unique-boundary-1--
Figure 18.8 Example
MIME Message Structure
FUNCTIONS S/MIME
provides the following functions.
•
Enveloped data: This consists of encrypted content
of any type
and encrypted- content encryption keys for one or more recipients.
•
Signed data: A digital signature
is formed by taking the message digest of the content to be signed and then
encrypting that with the private key of the signer. The content plus signature are then encoded using base64
encoding. A signed data message can only be viewed by a recipient with S/MIME capability.
•
Clear-signed data: As with signed data,
a digital signature of the content is formed.
However, in this case, only the digital
signature is encoded using base64. As a result,
recipients without S/MIME
capability can view
the message content, although
they cannot verify
the signature.
•
Signed and enveloped data: Signed-only and encrypted-only entities may be nested, so that encrypted data may be
signed and signed data or clear-signed data may be encrypted.
CRYPTOGRAPHIC ALGORITHMS Table 18.6 summarizes the cryptographic algorithms used in S/MIME. S/MIME uses the following terminology taken from RFC 2119 (Key Words for use in RFCs to Indicate Requirement Levels) to specify the requirement level:
•
MUST: The definition is an absolute requirement of the specification.
An implementation must include
this feature or function to be in conformance with the specification.
•
SHOULD: There may exist
valid reasons in particular circumstances to ignore this feature
or function, but it is recommended that an implementation include the feature or function.
S/MIME incorporates
three public-key algorithms.
The Digital
Signature Standard (DSS) described in Chapter 13 is the preferred algorithm for digital
signature. S/MIME lists Diffie-Hellman as the preferred algorithm for
encrypting session keys; in fact, S/MIME uses a variant of Diffie-Hellman that
does provide
Table
18.6 Cryptographic
Algorithms Used in S/MIME
encryption/decryption, known as ElGamal
(Chapter 10). As an alternative, RSA, described in Chapter 9, can be used for both signatures and session key encryption.
These are the same algorithms used in PGP and provide
a high level of security. For the
hash function used to create the digital signature, the specification requires the 160-bit SHA-1 but recommends receiver support for the 128-bit
MD5 for backward compatibility with older
versions of S/MIME.
As we discussed in Chapter
11, there is justifiable
concern about the security of MD5, so SHA-1 is clearly the preferred alternative.
For message encryption, three-key triple DES
(tripleDES) is recommended, but compliant implementations must support 40-bit
RC2. The latter is a weak encryption algorithm but allows compliance with U.S.
export controls.
The S/MIME specification includes a discussion of the
procedure for deciding which content encryption algorithm to use. In essence, a
sending agent has two deci- sions to make. First, the sending agent must
determine if the receiving agent is capa- ble of decrypting using a given
encryption algorithm. Second, if the receiving agent is only
capable of accepting weakly encrypted
content, the sending agent must decide if it is acceptable to send using weak encryption. To support this decision process, a sending
agent may announce its decrypting capabilities in order of prefer- ence for any
message that it sends out. A receiving agent may store that information for
future use.
The following rules, in the following order,
should be followed by a sending agent.
If the sending
agent has a list of preferred decrypting capabilities from an intended recipient, it SHOULD choose the
first (highest preference) capabil-
ity on the list that it is capable of using.
1.
If the sending
agent has no such list of capabilities from an intended
recipient but has
received one or more messages from the recipient, then the outgoing mes- sage SHOULD use the same encryption algorithm as was used on the last signed
and encrypted message
received from that intended recipient.
2.
If the sending agent has no knowledge about the decryption capabilities of the intended recipient and is willing to
risk that the recipient may not be able to decrypt the message,
then the sending
agent SHOULD use triple DES.
3.
If the sending agent
has no knowledge about the decryption capabilities of the intended recipient and is not willing to risk that the recipient may not be able
to decrypt the message, then the sending
agent MUST use RC2/40.
If a message is to be sent to multiple
recipients and a common encryption algorithm cannot be selected for all, then
the sending agent will need to send two messages. However, in that case, it is important to note that the security
of the mes- sage is made vulnerable by the transmission of one copy with lower security.
S/MIME
Messages
S/MIME makes use of a number of new MIME
content types, which are shown in Table 18.7. All of the new application types use the designation PKCS. This
refers to a set of public-key
cryptography specifications issued by RSA Laboratories and made available for the S/MIME effort.
We examine each of these in turn after first looking at the general
procedures for S/MIME message
preparation.
SECURING A MIME ENTITY S/MIME secures a
MIME entity with a signature, encryption,
or both. A MIME entity may be an entire message
(except for the RFC 5322 headers), or if the MIME content
type is multipart, then a MIME entity is one
or more of the subparts
of the message. The MIME entity is prepared
according to the normal rules for MIME message preparation. Then the
MIME entity plus some security-related data,
such as algorithm identifiers and certificates, are processed by S/MIME
to produce what is known
as a PKCS object. A PKCS object is then treated as message
content and wrapped in MIME (provided with appropriate MIME headers). This process should become clear as we look at specific objects
and provide examples.
In all cases, the message
to be sent is converted
to canonical form. In particu- lar, for a given
type and subtype,
the appropriate canonical form is used for the mes-
sage content. For a multipart
message, the appropriate canonical form is used for each subpart.
The use of transfer
encoding requires special attention. For most cases, the result of
applying the security
algorithm will be to produce an object
that is partially
or totally represented in arbitrary binary data. This will then be wrapped in an outer MIME
message, and transfer
encoding can
be applied at that point, typically base64. However,
in the case of a multipart signed message (described in more detail
later), the message content in one of the subparts is unchanged
by the security process. Unless that content
is 7bit, it should be transfer
encoded using base64 or quoted-printable so that there is no danger
of altering the content to which the signature was applied.
We now look at each of the S/MIME content
types.
ENVELOPEDDATA An application/pkcs7-mime subtype is used for one of four
categories of S/MIME processing, each with a unique smime-type parameter. In all cases, the resulting entity (referred
to as an object) is represented in a
form known as Basic Encoding Rules (BER), which is defined in ITU-T Recommendation
The BER format
consists of arbitrary octet strings and is therefore binary data. Such an
object should be transfer encoded with base64 in the outer MIME message. We first look at envelopedData.
The steps for preparing an envelopedData
MIME entity are
1.
Generate a
pseudorandom session key for a particular symmetric encryp- tion algorithm
(RC2/40 or triple DES).
2.
For each recipient, encrypt the session key with the recipient’s public RSA key.
3.
For each recipient, prepare a block known as RecipientInfo that contains an identifier of the recipient’s public-key certificate,4 an identifier of the algo-
rithm used to encrypt the session
key, and the encrypted session key.
4.
Encrypt the message content
with the session
key.
The RecipientInfo blocks followed by the
encrypted content constitute the envelopedData. This information is then encoded
into base64. A sample message (excluding the RFC 5322 headers)
is
Content-Type: application/pkcs7-mime; smime-type=enveloped- data; name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename=smime.p7m
rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 0GhIGfHfQbnj756YT64V
To recover the encrypted message, the
recipient first strips off the base64 encoding. Then the recipient’s private
key is used to recover the session key. Finally, the message content is
decrypted with the session key.
SIGNEDDATA The signedData smime-type can be used with one or more signers.
For clarity,
we confine our description to the case of a single digital signature. The steps
for preparing a signedData MIME entity are
1.
Select a message digest algorithm (SHA or MD5).
2.
Compute the message
digest (hash function) of the content to be signed.
3.
Encrypt the message
digest with the
signer’s private key.
4.
Prepare a block known as SignerInfo that contains
the signer’s public- key certificate, an identifier of the message
digest algorithm, an identifier of the algorithm used to encrypt the
message digest, and the encrypted mes- sage
digest.
The signedData
entity consists of a series
of blocks, including a message digest
algorithm identifier, the message being signed, and SignerInfo. The
signedData entity may also include
a set of public-key certificates sufficient to
constitute a chain from a recognized root or top-level certification authority
to the signer. This information is then encoded
into base64. A sample message
(excluding the RFC 5322 headers) is
Content-Type: application/pkcs7-mime; smime-type=signed-
data; name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename=smime.p7m
567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7
77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH
HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh 6YT64V0GhIGfHfQbnj75
To recover the
signed message and verify the signature, the recipient first
strips off the base64 encoding. Then the signer’s public key is used to
decrypt the message digest. The recipient
independently computes the message digest and com- pares it to the decrypted message
digest to verify
the signature.
CLEAR SIGNING Clear signing is achieved using the multipart content type
with a signed subtype. As was mentioned, this signing process does not involve
transforming the message to be signed, so that the message is sent “in
the clear.” Thus, recipients with MIME capability but not S/MIME capability are able to read
the incoming message.
A multipart/signed message has two parts.
The first part can be any MIME type but must be prepared so that it will not be
altered during transfer from source
to destination. This means that if the first part is not 7bit, then it needs to be encoded
using base64 or quoted-printable. Then
this part is processed in the same manner as signedData, but in this case an object with signedData
format is created that has an empty message content field.
This object is a detached signature. It is then transfer encoded using base64
to become the second part of the multipart/signed message. This
second part has a MIME content type of application and a subtype
of pkcs7-signature. Here is a sample
message:
Content-Type: multipart/signed;
protocol="application/pkcs7-signature"; micalg=sha1;
boundary=boundary42
—boundary42
Content-Type: text/plain
This is a clear-signed message.
—boundary42
Content-Type:
application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename=smime.p7s
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756
—boundary42—
The protocol parameter indicates that this is a two-part
clear-signed entity. The micalg parameter indicates the type of message digest
used. The receiver can verify the signature by taking the message digest
of the first part and comparing this to
the message digest recovered from the signature
in the second part.
REGISTRATION REQUEST Typically, an application or user will apply to a certification authority for
a public-key certificate. The application/pkcs10 S/MIME
entity is used
to transfer a certification request. The certification request
includes certification RequestInfo block,
followed by an identifier of the public-key encryption algorithm, followed by the signature of the certificationRequestInfo block made using
the sender’s private
key. The certificationRequestInfo block includes a name of the certificate subject (the
entity whose public key is to be certified)
and a bit-string representation of the user’s public
key.
CERTIFICATES-ONLY
MESSAGE A message
containing only certificates or a certificate revocation list (CRL) can be sent in response
to a registration request. The message is an application/pkcs7-mime type/subtype with an smime-type parameter of degenerate. The steps
involved are the same as those for creating a signedData message, except that
there is no message content and
the signerInfo field is empty.
S/MIME Certificate Processing
S/MIME uses public-key
certificates that conform to version 3 of X.509 (see Chapter
14). The key-management scheme
used by S/MIME
is in some ways a hybrid
between a strict X.509 certification hierarchy
and PGP’s web of trust. As
with the PGP model, S/MIME
managers and/or users
must configure each client
with a list of trusted
keys and with certificate revocation lists. That is, the responsi-
bility is local for maintaining the certificates needed to verify incoming signatures and to encrypt outgoing
messages. On the other hand,
the certificates are signed by certification authorities.
USER
AGENT
ROLE
An S/MIME user has several
key-management functions to perform.
•
Key generation: The user of some related
administrative utility (e.g., one asso-
ciated with LAN management) MUST be capable of generating separate Diffie-Hellman and DSS key pairs
and SHOULD be capable of generating RSA key pairs. Each
key pair MUST be generated from a good source of non-
deterministic random input
and be protected in a secure fashion.
A user agent SHOULD generate RSA key pairs
with a length in the range of 768 to 1024 bits and
MUST NOT generate
a length of less than 512 bits.
•
Registration: A user’s public
key must be registered with a
certification authority in order to receive an X.509 public-key certificate.
•
Certificate storage and retrieval: A user requires access
to a local list of certifi-
cates in order to verify
incoming signatures and to encrypt
outgoing messages. Such a
list could be maintained by the user or by some local administrative entity on behalf of a number
of users.
VERISIGN CERTIFICATES There are several companies that provide certification authority (CA) services.
For example,
Nortel
has designed an enterprise CA solution
and can provide S/MIME support within an organization. There are a number
of Internet-based CAs, including
VeriSign, GTE, and the U.S. Postal Service. Of these, the most widely
used is the VeriSign CA service, a brief description of which we now provide.
VeriSign provides a CA service
that is intended to be compatible with S/MIME and a variety of other applications. VeriSign issues
X.509 certificates with the product name VeriSign Digital
ID. As of early
1998, over 35,000
commercial Web sites were using VeriSign Server
Digital IDs, and over a million
consumer Digital IDs had been issued to users of Netscape and
Microsoft browsers.
The information contained in a Digital ID
depends on the type of Digital ID and its use. At a minimum, each Digital ID
contains
•
Owner’s public key
•
Owner’s name or alias
•
Expiration date of
the Digital ID
•
Serial number of the
Digital ID
•
Name of the certification authority that issued
the Digital ID
•
Digital signature
of the certification authority that issued the Digital ID
Digital IDs can also contain other
user-supplied information, including
•
Address
•
E-mail address
•
Basic registration information (country,
zip code, age,
and gender)
VeriSign provides three
levels, or classes,
of security for public-key certificates, as summarized in Table 18.8.
A user requests a certificate online at VeriSign’s Web site or other
participating Web sites. Class 1 and Class 2 requests are processed on line, and in most cases
take only a few seconds
to approve. Briefly, the following
procedures are used.
•
For Class 1 Digital
IDs, VeriSign confirms the user’s e-mail
address by sending a PIN and Digital ID pick-up
information to the e-mail address provided in the application.
•
For Class 2 Digital IDs,
VeriSign verifies the information in the application through an automated
comparison with a consumer database in addition
to
Table
18.8 Verisign
Public-Key Certificate Classes
performing all of the checking associated
with a Class 1 Digital ID. Finally, confirmation is sent to the specified
postal address alerting the user that a Digital ID has been issued in his or
her name.
•
For Class 3 Digital IDs, VeriSign requires
a higher level of identity
assurance. An individual must prove his or her identity by providing
notarized creden- tials or applying
in person.
Enhanced Security Services
As of this writing, three enhanced security
services have been proposed in an Internet draft. The details of these may
change, and additional services may be added. The three services are
•
Signed receipts: A signed receipt
may be requested in a SignedData object. Returning a signed receipt provides proof of
delivery to the originator of a message and allows the originator to
demonstrate to a third party that the recipient received
the message. In essence, the recipient signs
the entire origi- nal message plus the original (sender’s) signature and appends
the new signa- ture to form a new S/MIME message.
•
Security labels: A security
label may be included in the authenticated attrib- utes of a SignedData object. A security
label is a set of security information regarding the sensitivity of the content
that is protected by S/MIME encapsu-
lation. The labels may be used for access
control, by indicating which users are permitted access to an object. Other uses include
priority (secret, confidential, restricted, and so on) or
role based, describing which kind of people can see the information (e.g., patient’s health-care team, medical billing
agents, etc.).
Secure mailing lists: When a user sends a message
to multiple recipients, a cer- tain amount of
per-recipient processing is required, including the use of each recipient’s
public key. The user can be relieved of this work by employing the services
of an S/MIME Mail List Agent (MLA). An MLA can take a single incoming message,
perform the recipient-specific encryption for each recipi- ent, and forward the
message. The originator of a message
need only send the message to the MLA with encryption performed using the MLA’s public key.
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.