draft-ietf-smime-msg-02.txt   draft-ietf-smime-msg-03.txt 
Internet Draft Editor: Blake Ramsdell, Internet Draft Editor: Blake Ramsdell,
draft-ietf-smime-msg-02.txt Worldtalk draft-ietf-smime-msg-03.txt Worldtalk
March 11, 1998 March 24, 1998
Expires in six months Expires in six months
S/MIME Version 3 Message Specification S/MIME Version 3 Message Specification
Status of this memo Status of this memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the To view the entire list of current Internet-Drafts, please check
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow the "1id-abstracts.txt" listing contained in the Internet-Drafts
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
ftp.isi.edu (US West Coast). (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
1. Introduction 1. Introduction
S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a
consistent way to send and receive secure MIME data. Based on the consistent way to send and receive secure MIME data. Based on the
popular Internet MIME standard, S/MIME provides the following popular Internet MIME standard, S/MIME provides the following
cryptographic security services for electronic messaging applications: cryptographic security services for electronic messaging applications:
authentication, message integrity and non-repudiation of origin (using authentication, message integrity and non-repudiation of origin (using
digital signatures) and privacy and data security (using encryption). digital signatures) and privacy and data security (using encryption).
skipping to change at line 129 skipping to change at line 130
as part of a <CR><LF> end of line delimiter. as part of a <CR><LF> end of line delimiter.
Binary data: Arbitrary data. Binary data: Arbitrary data.
Transfer Encoding: A reversible transformation made on data so 8-bit Transfer Encoding: A reversible transformation made on data so 8-bit
or binary data may be sent via a channel that only transmits 7-bit or binary data may be sent via a channel that only transmits 7-bit
data. data.
1.4 Compatibility with Prior Practice of S/MIME 1.4 Compatibility with Prior Practice of S/MIME
Appendix C contains important information about how S/MIME agents S/MIME version 3 agents should attempt to have the greatest
following this specification should act in order to have the greatest interoperability possible with S/MIME version 2 agents. S/MIME version
interoperability with earlier implementations of S/MIME. 2 is described in RFC 2311 through RFC 2315, inclusive. RFC 2311 also
has historical information about the development of S/MIME.
1.5 Discussion of This Draft 1.5 Discussion of This Draft
This draft is being discussed on the "ietf-smime" mailing list. To This draft is being discussed on the "ietf-smime" mailing list. To
subscribe, send a message to: subscribe, send a message to:
ietf-smime-request@imc.org ietf-smime-request@imc.org
with the single word with the single word
skipping to change at line 157 skipping to change at line 159
2. CMS Options 2. CMS Options
CMS allows for a wide variety of options in content and algorithm CMS allows for a wide variety of options in content and algorithm
support. This section puts forth a number of support requirements and support. This section puts forth a number of support requirements and
recommendations in order to achieve a base level of interoperability recommendations in order to achieve a base level of interoperability
among all S/MIME implementations. [CMS] provides additional details among all S/MIME implementations. [CMS] provides additional details
regarding the use of the cryptographic algorithms. regarding the use of the cryptographic algorithms.
2.1 DigestAlgorithmIdentifier 2.1 DigestAlgorithmIdentifier
Receiving agents MUST support SHA-1 [SHA1]. Receiving agents SHOULD Sending and receiving agents MUST support SHA-1 [SHA1]. Receiving
support MD5 [MD5] for the purpose of providing backward compatibility agents SHOULD support MD5 [MD5] for the purpose of providing backward
with MD5-digested S/MIME v2 SignedData objects. compatibility with MD5-digested S/MIME v2 SignedData objects.
Sending agents SHOULD use SHA-1.
2.2 SignatureAlgorithmIdentifier 2.2 SignatureAlgorithmIdentifier
Sending and receiving agents MUST support id-dsa defined in [DSS]. Sending and receiving agents MUST support id-dsa defined in [DSS].
The algorithm parameters MUST be absent (not encoded as NULL). The algorithm parameters MUST be absent (not encoded as NULL).
Receiving agents SHOULD support rsaEncryption, defined in [PKCS-1]. Receiving agents SHOULD support rsaEncryption, defined in [PKCS-1].
Receiving agents SHOULD support verification of signatures using RSA Receiving agents SHOULD support verification of signatures using RSA
public key sizes from 512 bits to 1024 bits. public key sizes from 512 bits to 1024 bits.
skipping to change at line 198 skipping to change at line 198
RSA public keys at key sizes from 512 bits to 1024 bits. RSA public keys at key sizes from 512 bits to 1024 bits.
2.4 General Syntax 2.4 General Syntax
CMS defines multiple content types. Of these, only the Data, CMS defines multiple content types. Of these, only the Data,
SignedData, and EnvelopedData content types are currently used for SignedData, and EnvelopedData content types are currently used for
S/MIME. S/MIME.
2.4.1 Data Content Type 2.4.1 Data Content Type
Sending agents MUST use the "data" content type as the content within Sending agents MUST use the id-data content type identifier to
other content types to indicate the message content which has had indicate the message content which has had security services applied
security services applied to it. to it. For example, when applying a digital signature to MIME data,
the CMS signedData encapContentInfo eContentType MUST include the id-
data object identifier and the MIME content MUST be stored in the
SignedData encapContentInfo eContent OCTET STRING. As another
example, when applying encryption to MIME data, the CMS EnvelopedData
encryptedContentInfo ContentType MUST include the id-data object
identifier and the encrypted MIME content MUST be stored in the
envelopedData encryptedContentInfo encryptedContent OCTET STRING.
2.4.2 SignedData Content Type 2.4.2 SignedData Content Type
Sending agents MUST use the signedData content type to apply a digital Sending agents MUST use the signedData content type to apply a digital
signature to a message or, in a degenerate case where there is no signature to a message or, in a degenerate case where there is no
signature information, to convey certificates. signature information, to convey certificates.
2.4.3 EnvelopedData Content Type 2.4.3 EnvelopedData Content Type
This content type is used to apply privacy protection to a message. A This content type is used to apply privacy protection to a message. A
skipping to change at line 224 skipping to change at line 231
2.5 Attribute SignerInfo Type 2.5 Attribute SignerInfo Type
The SignerInfo type allows the inclusion of unauthenticated and The SignerInfo type allows the inclusion of unauthenticated and
authenticated attributes to be included along with a signature. authenticated attributes to be included along with a signature.
Receiving agents MUST be able to handle zero or one instance of each Receiving agents MUST be able to handle zero or one instance of each
of the signed attributes described in this section. of the signed attributes described in this section.
Sending agents SHOULD be able to generate one instance of each of the Sending agents SHOULD be able to generate one instance of each of the
signed attributes described in this section, and SHOULD include these signed attributes described in this section, and SHOULD include the
attributes in each signed message sent. signing time and SMIMECapabilities attribute in each signed message
sent.
Additional attributes and values for these attributes may be defined Additional attributes and values for these attributes may be defined
in the future. Receiving agents SHOULD handle attributes or values in the future. Receiving agents SHOULD handle attributes or values
that it does not recognize in a graceful manner. that it does not recognize in a graceful manner.
2.5.1 Signing-Time Attribute 2.5.1 Signing-Time Attribute
The signing-time attribute is used to convey the time that a message The signing-time attribute is used to convey the time that a message
was signed. Until there are trusted timestamping services, the time of was signed. Until there are trusted timestamping services, the time of
signing will most likely be created by a message originator and signing will most likely be created by a message originator and
therefore is only as trustworthy as the originator. therefore is only as trustworthy as the originator.
Sending agents MUST encode signing time through the year 2049 as Sending agents MUST encode signing time through the year 2049 as
UTCTime; signing times in 2050 or later MUST be encoded as UTCTime; signing times in 2050 or later MUST be encoded as
GeneralizedTime. Agents MUST interpret the year field (YY) as follows: GeneralizedTime. When the UTCTime CHOICE is used, agents MUST
interpret the year field (YY) as follows:
if YY is greater than or equal to 50, the year is interpreted as 19YY; if YY is greater than or equal to 50, the year is interpreted as 19YY;
if YY is less than 50, the year is interpreted as 20YY. if YY is less than 50, the year is interpreted as 20YY.
2.5.2 SMIMECapabilities Attribute 2.5.2 SMIMECapabilities Attribute
The SMIMECapabilities attribute includes signature algorithms (such as The SMIMECapabilities attribute includes signature algorithms (such as
"md5WithRSAEncryption"), symmetric algorithms (such as "DES-CBC"), and "md5WithRSAEncryption"), symmetric algorithms (such as "DES-CBC"), and
key encipherment algorithms (such as "rsaEncryption"). It also key encipherment algorithms (such as "rsaEncryption"). It also
includes a non-algorithm capability which is the preference for includes a non-algorithm capability which is the preference for
skipping to change at line 332 skipping to change at line 341
the message is valid and the signing time is greater than the the message is valid and the signing time is greater than the
currently stored value. (As with the SMIMECapabilities, the clock currently stored value. (As with the SMIMECapabilities, the clock
skew should be checked and the data not used if the skew is to great.) skew should be checked and the data not used if the skew is to great.)
Receiving agents SHOULD respect the senders encryption key preference Receiving agents SHOULD respect the senders encryption key preference
attribute if possible. This however represents only a preference and attribute if possible. This however represents only a preference and
the receiving agent may use any certificate in replying to the sender the receiving agent may use any certificate in replying to the sender
that is valid. that is valid.
2.6 ContentEncryptionAlgorithmIdentifier 2.6 ContentEncryptionAlgorithmIdentifier
Receiving agents MUST support encryption and decryption with DES EDE3 Sending and receiving agents MUST support encryption and decryption
CBC, hereinafter called "tripleDES" [3DES] [DES]. Receiving agents with DES EDE3 CBC, hereinafter called "tripleDES" [3DES] [DES].
SHOULD support encryption and decryption using the RC2 [RC2] or a Receiving agents SHOULD support encryption and decryption using the
compatible algorithm at a key size of 40 bits, hereinafter called RC2 [RC2] or a compatible algorithm at a key size of 40 bits,
"RC2/40". hereinafter called "RC2/40".
2.6.1 Deciding Which Encryption Method To Use 2.6.1 Deciding Which Encryption Method To Use
When a sending agent creates an encrypted message, it has to decide When a sending agent creates an encrypted message, it has to decide
which type of encryption to use. The decision process involves using which type of encryption to use. The decision process involves using
information garnered from the capabilities lists included in messages information garnered from the capabilities lists included in messages
received from the recipient, as well as out-of-band information such received from the recipient, as well as out-of-band information such
as private agreements, user preferences, legal restrictions, and so as private agreements, user preferences, legal restrictions, and so
on. on.
skipping to change at line 364 skipping to change at line 373
for the sender's public key, then, after verifying the signature for the sender's public key, then, after verifying the signature
on the incoming message and checking the timestamp, the receiving on the incoming message and checking the timestamp, the receiving
agent SHOULD create a new list containing at least the signing agent SHOULD create a new list containing at least the signing
time and the symmetric capabilities. time and the symmetric capabilities.
- If such a list already exists, the receiving agent SHOULD verify - If such a list already exists, the receiving agent SHOULD verify
that the signing time in the incoming message is greater than that the signing time in the incoming message is greater than
the signing time stored in the list and that the signature is the signing time stored in the list and that the signature is
valid. If so, the receiving agent SHOULD update both the signing valid. If so, the receiving agent SHOULD update both the signing
time and capabilities in the list. Values of the signing time that time and capabilities in the list. Values of the signing time that
lie far in the future (that is, a greater discrepancy than any lie far in the future (that is, a greater discrepancy than any
reasonable clock skew), or a capabilitie lists in messages whose reasonable clock skew), or a capabilities list in messages whose
signature could not be verified, MUST NOT be accepted. signature could not be verified, MUST NOT be accepted.
The list of capabilities SHOULD be stored for future use in creating The list of capabilities SHOULD be stored for future use in creating
messages. messages.
Before sending a message, the sending agent MUST decide whether it is Before sending a message, the sending agent MUST decide whether it is
willing to use weak encryption for the particular data in the message. willing to use weak encryption for the particular data in the message.
If the sending agent decides that weak encryption is unacceptable for If the sending agent decides that weak encryption is unacceptable for
this data, then the sending agent MUST NOT use a weak algorithm such this data, then the sending agent MUST NOT use a weak algorithm such
as RC2/40. The decision to use or not use weak encryption overrides as RC2/40. The decision to use or not use weak encryption overrides
any other decision in this section about which encryption algorithm to any other decision in this section about which encryption algorithm to
use. use.
Sections 2.6.2.1 through 2.6.2.4 describe the decisions a sending Sections 2.6.2.1 through 2.6.2.4 describe the decisions a sending
agent SHOULD use in deciding which type of encryption should be agent SHOULD use in deciding which type of encryption should be
applied to a message. These rules are ordered, so the sending agent applied to a message. These rules are ordered, so the sending agent
SHOULD make its decision in the order given. SHOULD make its decision in the order given.
2.6.2.1 Rule 1: Known Capabilities 2.6.1.1 Rule 1: Known Capabilities
If the sending agent has received a set of capabilities from the If the sending agent has received a set of capabilities from the
recipient for the message the agent is about to encrypt, then the recipient for the message the agent is about to encrypt, then the
sending agent SHOULD use that information by selecting the first sending agent SHOULD use that information by selecting the first
capability in the list (that is, the capability most preferred by the capability in the list (that is, the capability most preferred by the
intended recipient) for which the sending agent knows how to encrypt. intended recipient) for which the sending agent knows how to encrypt.
The sending agent SHOULD use one of the capabilities in the list if The sending agent SHOULD use one of the capabilities in the list if
the agent reasonably expects the recipient to be able to decrypt the the agent reasonably expects the recipient to be able to decrypt the
message. message.
2.6.2.2 Rule 2: Unknown Capabilities, Known Use of Encryption 2.6.1.2 Rule 2: Unknown Capabilities, Known Use of Encryption
If: If:
- the sending agent has no knowledge of the encryption capabilities - the sending agent has no knowledge of the encryption capabilities
of the recipient, of the recipient,
- and the sending agent has received at least one message from the - and the sending agent has received at least one message from the
recipient, recipient,
- and the last encrypted message received from the recipient had a - and the last encrypted message received from the recipient had a
trusted signature on it, trusted signature on it,
then the outgoing message SHOULD use the same encryption algorithm as then the outgoing message SHOULD use the same encryption algorithm as
was used on the last signed and encrypted message received from the was used on the last signed and encrypted message received from the
recipient. recipient.
2.6.2.3 Rule 3: Unknown Capabilities, Risk of Failed Decryption 2.6.1.3 Rule 3: Unknown Capabilities, Risk of Failed Decryption
If: If:
- the sending agent has no knowledge of the encryption capabilities - the sending agent has no knowledge of the encryption capabilities
of the recipient, of the recipient,
- and the sending agent is willing to risk that the recipient may - and the sending agent is willing to risk that the recipient may
not be able to decrypt the message, not be able to decrypt the message,
then the sending agent SHOULD use tripleDES. then the sending agent SHOULD use tripleDES.
2.6.2.4 Rule 4: Unknown Capabilities, No Risk of Failed Decryption 2.6.1.4 Rule 4: Unknown Capabilities, No Risk of Failed Decryption
If: If:
- the sending agent has no knowledge of the encryption capabilities - the sending agent has no knowledge of the encryption capabilities
of the recipient, of the recipient,
- and the sending agent is not willing to risk that the recipient - and the sending agent is not willing to risk that the recipient
may not be able to decrypt the message, may not be able to decrypt the message,
then the sending agent SHOULD use RC2/40. then the sending agent SHOULD use RC2/40.
2.6.3 Choosing Weak Encryption 2.6.2 Choosing Weak Encryption
Like all algorithms that use 40 bit keys, RC2/40 is considered by many Like all algorithms that use 40 bit keys, RC2/40 is considered by many
to be weak encryption. A sending agent that is controlled by a human to be weak encryption. A sending agent that is controlled by a human
SHOULD allow a human sender to determine the risks of sending data SHOULD allow a human sender to determine the risks of sending data
using RC2/40 or a similarly weak encryption algorithm before sending using RC2/40 or a similarly weak encryption algorithm before sending
the data, and possibly allow the human to use a stronger encryption the data, and possibly allow the human to use a stronger encryption
method such as tripleDES. method such as tripleDES.
2.6.4 Multiple Recipients 2.6.3 Multiple Recipients
If a sending agent is composing an encrypted message to a group of If a sending agent is composing an encrypted message to a group of
recipients where the encryption capabilities of some of the recipients recipients where the encryption capabilities of some of the recipients
do not overlap, the sending agent is forced to send more than one do not overlap, the sending agent is forced to send more than one
message. It should be noted that if the sending agent chooses to send message. It should be noted that if the sending agent chooses to send
a message encrypted with a strong algorithm, and then send the same a message encrypted with a strong algorithm, and then send the same
message encrypted with a weak algorithm, someone watching the message encrypted with a weak algorithm, someone watching the
communications channel can decipher the contents of the strongly- communications channel can decipher the contents of the strongly-
encrypted message simply by decrypting the weakly-encrypted message. encrypted message simply by decrypting the weakly-encrypted message.
3. Creating S/MIME Messages 3. Creating S/MIME Messages
This section describes the S/MIME message formats and how they are This section describes the S/MIME message formats and how they are
created. S/MIME messages are a combination of MIME bodies and CMS created. S/MIME messages are a combination of MIME bodies and CMS
objects. Several MIME types as well as several CMS objects are used. objects. Several MIME types as well as several CMS objects are used.
The data to be secured is always a canonical MIME entity. The MIME The data to be secured is always a canonical MIME entity. The MIME
entity and other data, such as certificates and algorithm identifiers, entity and other data, such as certificates and algorithm identifiers,
are given to CMS processing facilities which produces a PKCS object. are given to CMS processing facilities which produces a CMS object.
The CMS object is then finally wrapped in MIME. The CMS object is then finally wrapped in MIME. The Enhanced Security
Services for S/MIME [ESS] document provides examples of how nested,
secured S/MIME messages are formatted. ESS provides an example of how
a triple-wrapped S/MIME message is formatted using multipart/signed
and application/pkcs7-mime for the signatures.
S/MIME provides one format for enveloped-only data, several formats S/MIME provides one format for enveloped-only data, several formats
for signed-only data, and several formats for signed and enveloped for signed-only data, and several formats for signed and enveloped
data. Several formats are required to accommodate several data. Several formats are required to accommodate several
environments, in particular for signed messages. The criteria for environments, in particular for signed messages. The criteria for
choosing among these formats are also described. choosing among these formats are also described.
The reader of this section is expected to understand MIME as described The reader of this section is expected to understand MIME as described
in [MIME-SPEC] and [MIME-SECURE]. in [MIME-SPEC] and [MIME-SECURE].
skipping to change at line 642 skipping to change at line 655
--bar-- --bar--
3.2 The application/pkcs7-mime Type 3.2 The application/pkcs7-mime Type
The application/pkcs7-mime type is used to carry CMS objects of The application/pkcs7-mime type is used to carry CMS objects of
several types including envelopedData and signedData. The details of several types including envelopedData and signedData. The details of
constructing these entities is described in subsequent sections. This constructing these entities is described in subsequent sections. This
section describes the general characteristics of the application/pkcs7- section describes the general characteristics of the application/pkcs7-
mime type. mime type.
This MIME type always carries a single CMS object. The CMS object must The carried CMS object always contains a MIME entity that is prepared
always be the BER encoding of the ASN.1 syntax describing the object. as described in section 3.1 if the eContentType is id-data. Other
The contentInfo field of the carried CMS object always contains a MIME contents may be carried when the eContentType contains different
entity that is prepared as described in section 3.1. The contentInfo values. See [ESS] for an example of this with signed receipts.
field must never be empty.
Since CMS objects are binary data, in most cases base-64 transfer Since CMS objects are binary data, in most cases base-64 transfer
encoding is appropriate, in particular when used with SMTP transport. encoding is appropriate, in particular when used with SMTP transport.
The transfer encoding used depends on the transport through which the The transfer encoding used depends on the transport through which the
object is to be sent, and is not a characteristic of the MIME type. object is to be sent, and is not a characteristic of the MIME type.
Note that this discussion refers to the transfer encoding of the CMS Note that this discussion refers to the transfer encoding of the CMS
object or "outside" MIME entity. It is completely distinct from, and object or "outside" MIME entity. It is completely distinct from, and
unrelated to, the transfer encoding of the MIME entity secured by the unrelated to, the transfer encoding of the MIME entity secured by the
CMS object, the "inside" object, which is described in section 3.1. CMS object, the "inside" object, which is described in section 3.1.
skipping to change at line 740 skipping to change at line 752
Content-Disposition: attachment; filename=smime.p7m Content-Disposition: attachment; filename=smime.p7m
rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
0GhIGfHfQbnj756YT64V 0GhIGfHfQbnj756YT64V
3.4 Creating a Signed-only Message 3.4 Creating a Signed-only Message
There are two formats for signed messages defined for S/MIME: There are two formats for signed messages defined for S/MIME:
application/pkcs7-mime and SignedData, and multipart/signed. In application/pkcs7-mime with SignedData, and multipart/signed. In
general, the multipart/signed form is preferred for sending, and general, the multipart/signed form is preferred for sending, and
receiving agents SHOULD be able to handle both. receiving agents SHOULD be able to handle both.
3.4.1 Choosing a Format for Signed-only Messages 3.4.1 Choosing a Format for Signed-only Messages
There are no hard-and-fast rules when a particular signed-only format There are no hard-and-fast rules when a particular signed-only format
should be chosen because it depends on the capabilities of all the should be chosen because it depends on the capabilities of all the
receivers and the relative importance of receivers with S/MIME receivers and the relative importance of receivers with S/MIME
facilities being able to verify the signature versus the importance of facilities being able to verify the signature versus the importance of
receivers without S/MIME software being able to view the message. receivers without S/MIME software being able to view the message.
skipping to change at line 765 skipping to change at line 777
have messages translated by a gateway. In this context, "be viewed" have messages translated by a gateway. In this context, "be viewed"
means the ability to process the message essentially as if it were not means the ability to process the message essentially as if it were not
a signed message, including any other MIME structure the message might a signed message, including any other MIME structure the message might
have. have.
Messages signed using the signedData format cannot be viewed by a Messages signed using the signedData format cannot be viewed by a
recipient unless they have S/MIME facilities. However, if they have recipient unless they have S/MIME facilities. However, if they have
S/MIME facilities, these messages can always be verified if they were S/MIME facilities, these messages can always be verified if they were
not changed in transit. not changed in transit.
3.4.2 Signing Using application/pkcs7-mime and SignedData 3.4.2 Signing Using application/pkcs7-mime with SignedData
This signing format uses the application/pkcs7-mime MIME type. The This signing format uses the application/pkcs7-mime MIME type. The
steps to create this format are: steps to create this format are:
Step 1. The MIME entity is prepared according to section 3.1 Step 1. The MIME entity is prepared according to section 3.1
Step 2. The MIME entity and other required data is processed into a Step 2. The MIME entity and other required data is processed into a
CMS object of type signedData CMS object of type signedData
Step 3. The CMS object is inserted into an application/pkcs7-mime MIME Step 3. The CMS object is inserted into an application/pkcs7-mime MIME
entity entity
The smime-type parameter for messages using application/pkcs7-mime and The smime-type parameter for messages using application/pkcs7-mime
SignedData is "signed-data". The file extension for this type of with SignedData is "signed-data". The file extension for this type of
message is ".p7m". message is ".p7m".
A sample message would be: A sample message would be:
Content-Type: application/pkcs7-mime; smime-type=signed-data; Content-Type: application/pkcs7-mime; smime-type=signed-data;
name=smime.p7m name=smime.p7m
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m Content-Disposition: attachment; filename=smime.p7m
567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7
77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH
HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh
6YT64V0GhIGfHfQbnj75 6YT64V0GhIGfHfQbnj75
3.4.3 Signing Using the multipart/signed Format 3.4.3 Signing Using the multipart/signed Format
This format is a clear-signing format. Recipients without any S/MIME This format is a clear-signing format. Recipients without any S/MIME
or PKCS processing facilities are able to view the message. It makes or CMS processing facilities are able to view the message. It makes
use of the multipart/signed MIME type described in [MIME-SECURE]. The use of the multipart/signed MIME type described in [MIME-SECURE]. The
multipart/signed MIME type has two parts. The first part contains the multipart/signed MIME type has two parts. The first part contains the
MIME entity that is to be signed; the second part contains the MIME entity that is signed; the second part contains the "detached
signature, which is a CMS detached signature. signature" CMS SignedData object in which the encapContentInfo
eContent field is absent.
3.4.3.1 The application/pkcs7-signature MIME Type 3.4.3.1 The application/pkcs7-signature MIME Type
This MIME type always contains a single CMS object of type signedData. This MIME type always contains a single CMS object of type signedData.
The contentInfo field of the CMS object must be empty. The signerInfos The signedData encapContentInfo eContent field MUST be absent. The
field contains the signatures for the MIME entity. The details of the signerInfos field contains the signatures for the MIME entity. The
registered type are given in Appendix E. details of the registered type are given in Appendix E.
The file extension for signed-only messages using application/pkcs7- The file extension for signed-only messages using application/pkcs7-
signature is ".p7s". signature is ".p7s".
3.4.3.2 Creating a multipart/signed Message 3.4.3.2 Creating a multipart/signed Message
Step 1. The MIME entity to be signed is prepared according to section Step 1. The MIME entity to be signed is prepared according to section
3.1, taking special care for clear-signing. 3.1, taking special care for clear-signing.
Step 2. The MIME entity is presented to CMS processing in order to Step 2. The MIME entity is presented to CMS processing in order to
obtain an object of type signedData with an empty contentInfo field. obtain an object of type signedData in which the encapContentInfo
eContent field is absent.
Step 3. The MIME entity is inserted into the first part of a Step 3. The MIME entity is inserted into the first part of a
multipart/signed message with no processing other than that described multipart/signed message with no processing other than that described
in section 3.1. in section 3.1.
Step 4. Transfer encoding is applied to the detached signature and it Step 4. Transfer encoding is applied to the "detached signature" CMS
is inserted into a MIME entity of type application/pkcs7-signature SignedData object and it is inserted into a MIME entity of type
application/pkcs7-signature.
Step 5. The MIME entity of the application/pkcs7-signature is inserted Step 5. The MIME entity of the application/pkcs7-signature is inserted
into the second part of the multipart/signed entity into the second part of the multipart/signed entity.
The multipart/signed Content type has two required parameters: the The multipart/signed Content type has two required parameters: the
protocol parameter and the micalg parameter. protocol parameter and the micalg parameter.
The protocol parameter MUST be "application/pkcs7-signature". Note The protocol parameter MUST be "application/pkcs7-signature". Note
that quotation marks are required around the protocol parameter that quotation marks are required around the protocol parameter
because MIME requires that the "/" character in the parameter value because MIME requires that the "/" character in the parameter value
MUST be quoted. MUST be quoted.
The micalg parameter allows for one-pass processing when the signature The micalg parameter allows for one-pass processing when the signature
is being verified. The value of the micalg parameter is dependent on is being verified. The value of the micalg parameter is dependent on
the message digest algorithm used in the calculation of the Message the message digest algorithm(s) used in the calculation of the Message
Integrity Check. The value of the micalg parameter SHOULD be one of Integrity Check. If multiple message digest algorithms are used they
the following: MUST be separated by commas per [MIME-SECURE]. The values to be placed
in the micalg parameter SHOULD be from the following:
Algorithm Value Algorithm Value
used used
MD5 md5 MD5 md5
SHA-1 sha1 SHA-1 sha1
Any other unknown Any other unknown
(Historical note: some early implementations of S/MIME emitted and (Historical note: some early implementations of S/MIME emitted and
expected "rsa-md5" and "rsa-sha1" for the micalg parameter.) Receiving expected "rsa-md5" and "rsa-sha1" for the micalg parameter.) Receiving
skipping to change at line 914 skipping to change at line 930
is desired, as no private key material is required to verify a is desired, as no private key material is required to verify a
signature. signature.
3.6 Creating a Certificates-only Message 3.6 Creating a Certificates-only Message
The certificates only message or MIME entity is used to transport The certificates only message or MIME entity is used to transport
certificates, such as in response to a registration request. This certificates, such as in response to a registration request. This
format can also be used to convey CRLs. format can also be used to convey CRLs.
Step 1. The certificates are made available to the CMS generating Step 1. The certificates are made available to the CMS generating
process which creates a CMS object of type signedData. The contentInfo process which creates a CMS object of type signedData. The signedData
and signerInfos fields must be empty. encapContentInfo eContent field MUST be absent and signerInfos field
MUST be empty.
Step 2. The CMS signedData object is enclosed in an application/pkcs7- Step 2. The CMS signedData object is enclosed in an application/pkcs7-
mime MIME entity mime MIME entity
The smime-type parameter for a certs-only message is "certs-only". The smime-type parameter for a certs-only message is "certs-only".
The file extension for this type of message is ".p7c". The file extension for this type of message is ".p7c".
3.7 Registration Requests 3.7 Registration Requests
A sending agent that signs messages MUST have a certificate for the A sending agent that signs messages MUST have a certificate for the
skipping to change at line 942 skipping to change at line 959
with certificate authorities using an application/pkcs10 body part. with certificate authorities using an application/pkcs10 body part.
The IETF's PKIX Working Group is preparing another method for The IETF's PKIX Working Group is preparing another method for
requesting certificates; however, that work was not finished at the requesting certificates; however, that work was not finished at the
time of this draft. S/MIME v3 does not specify how to request a time of this draft. S/MIME v3 does not specify how to request a
certificate, but instead mandates that every sending agent already has certificate, but instead mandates that every sending agent already has
a certificate. a certificate.
S/MIME v3 does not specify the details of certificate management, but S/MIME v3 does not specify the details of certificate management, but
instead mandates that every sending agent already has a certificate. instead mandates that every sending agent already has a certificate.
Standardization of certificate management is being pursued separately Standardization of certificate management is being pursued separately
in the IETF. S/MIME v2 specified a non-standard technology for in the IETF.
certificate management.
3.8 Identifying an S/MIME Message 3.8 Identifying an S/MIME Message
Because S/MIME takes into account interoperation in non-MIME Because S/MIME takes into account interoperation in non-MIME
environments, several different mechanisms are employed to carry the environments, several different mechanisms are employed to carry the
type information, and it becomes a bit difficult to identify S/MIME type information, and it becomes a bit difficult to identify S/MIME
messages. The following table lists criteria for determining whether messages. The following table lists criteria for determining whether
or not a message is an S/MIME message. A message is considered an or not a message is an S/MIME message. A message is considered an
S/MIME message if it matches any below. S/MIME message if it matches any below.
skipping to change at line 982 skipping to change at line 998
MIME type: application/octet-stream MIME type: application/octet-stream
parameters: any parameters: any
file suffix: p7m, p7s, aps, p7c file suffix: p7m, p7s, aps, p7c
4. Certificate Processing 4. Certificate Processing
A receiving agent MUST provide some certificate retrieval mechanism in A receiving agent MUST provide some certificate retrieval mechanism in
order to gain access to certificates for recipients of digital order to gain access to certificates for recipients of digital
envelopes. This draft does not cover how S/MIME agents handle envelopes. This draft does not cover how S/MIME agents handle
certificates, only what they do after a certificate has been validated certificates, only what they do after a certificate has been validated
or rejected. S/MIME certification issues are covered in a different or rejected. S/MIME certification issues are covered in [CERT3].
document.
At a minimum, for initial S/MIME deployment, a user agent could At a minimum, for initial S/MIME deployment, a user agent could
automatically generate a message to an intended recipient requesting automatically generate a message to an intended recipient requesting
that recipient's certificate in a signed return message. Receiving and that recipient's certificate in a signed return message. Receiving and
sending agents SHOULD also provide a mechanism to allow a user to sending agents SHOULD also provide a mechanism to allow a user to
"store and protect" certificates for correspondents in such a way so "store and protect" certificates for correspondents in such a way so
as to guarantee their later retrieval. as to guarantee their later retrieval.
4.1 Key Pair Generation 4.1 Key Pair Generation
skipping to change at line 1006 skipping to change at line 1021
generating separate DH and DSS public/private key pairs on behalf of generating separate DH and DSS public/private key pairs on behalf of
the user. Each key pair MUST be generated from a good source of non- the user. Each key pair MUST be generated from a good source of non-
deterministic random input and the private key MUST be protected in a deterministic random input and the private key MUST be protected in a
secure fashion. secure fashion.
If an S/MIME agent needs to generate a key pair, then the S/MIME agent If an S/MIME agent needs to generate a key pair, then the S/MIME agent
or some related administrative utility or function SHOULD generate RSA or some related administrative utility or function SHOULD generate RSA
key pairs. key pairs.
A user agent SHOULD generate RSA key pairs at a minimum key size of A user agent SHOULD generate RSA key pairs at a minimum key size of
768 bits and a maximum key size of 1024 bits. A user agent MUST NOT 768 bits. A user agent MUST NOT generate RSA key pairs less than 512
generate RSA key pairs less than 512 bits long. Some agents created in bits long. Creating keys longer than 1024 bits may cause some older
the United States have chosen to create 512 bit keys in order to get S/MIME receiving agents to not be able to verify signatures, but gives
more advantageous export licenses. However, 512 bit keys are better security and is therefore valuable. A receiving agent SHOULD be
considered by many to be cryptographically insecure. Implementors able to verify signatures with keys of any size over 512 bits. Some
should be aware that multiple (active) key pairs may be associated agents created in the United States have chosen to create 512 bit keys
with a single individual. For example, one key pair may be used to in order to get more advantageous export licenses. However, 512 bit
support confidentiality, while a different key pair may be used for keys are considered by many to be cryptographically insecure.
authentication. Implementors should be aware that multiple (active) key pairs may be
associated with a single individual. For example, one key pair may be
used to support confidentiality, while a different key pair may be
used for authentication.
5. Security 5. Security
This entire draft discusses security. Security issues not covered in This entire draft discusses security. Security issues not covered in
other parts of the draft include: other parts of the draft include:
40-bit encryption is considered weak by most cryptographers. Using 40-bit encryption is considered weak by most cryptographers. Using
weak cryptography in S/MIME offers little actual security over sending weak cryptography in S/MIME offers little actual security over sending
plaintext. However, other features of S/MIME, such as the plaintext. However, other features of S/MIME, such as the
specification of tripleDES and the ability to announce stronger specification of tripleDES and the ability to announce stronger
skipping to change at line 1100 skipping to change at line 1118
CBCParameter :: IV CBCParameter :: IV
where IV ::= OCTET STRING -- 8 octets. where IV ::= OCTET STRING -- 8 octets.
A.2 Digest Algorithms A.2 Digest Algorithms
md5 OBJECT IDENTIFIER ::= md5 OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 5} {iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 5}
sha-1 OBJECT IDENTIFIER ::= sha-1 OBJECT IDENTIFIER ::=
{iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) {iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26}
26}
A.3 Asymmetric Encryption Algorithms A.3 Asymmetric Encryption Algorithms
rsaEncryption OBJECT IDENTIFIER ::= rsaEncryption OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1} {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1}
rsa OBJECT IDENTIFIER ::= rsa OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) algorithm(8) encryptionAlgorithm(1) 1} {joint-iso-ccitt(2) ds(5) algorithm(8) encryptionAlgorithm(1) 1}
id-dsa OBJECT IDENTIFIER ::= id-dsa OBJECT IDENTIFIER ::=
skipping to change at line 1142 skipping to change at line 1159
smimeCapabilities OBJECT IDENTIFIER ::= smimeCapabilities OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15} {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15}
B. References B. References
[3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES," [3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES,"
IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41. IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41.
[APP-MIME] "Wrapping MIME Objects: Application/MIME", Internet Draft [APP-MIME] "Wrapping MIME Objects: Application/MIME", Internet Draft
draft-crocker-wrap-01.txt. draft-crocker-wrap-*.txt.
[CERT3] "S/MIME Version 3 Certificate Handling", Internet Draft draft-
ietf-smime-cert-*.txt.
[CHARSETS] Character sets assigned by IANA. See <ftp://ftp.isi.edu/in- [CHARSETS] Character sets assigned by IANA. See <ftp://ftp.isi.edu/in-
notes/iana/assignments/character-sets>. notes/iana/assignments/character-sets>.
[CMS] "Cryptographic Message Syntax", Internet Draft draft-housley- [CMS] "Cryptographic Message Syntax", Internet Draft draft-ietf-smime-
smime-cms cms-*.txt.
[CONTDISP] "Communicating Presentation Information in Internet [CONTDISP] "Communicating Presentation Information in Internet
Messages: The Content-Disposition Header Field", RFC 2183 Messages: The Content-Disposition Header Field", RFC 2183
[DES] ANSI X3.106, "American National Standard for Information Systems- [DES] ANSI X3.106, "American National Standard for Information Systems-
Data Link Encryption," American National Standards Institute, 1983. Data Link Encryption," American National Standards Institute, 1983.
[DH] ANSI X9.42 TBD [DH] ANSI X9.42 TBD
[DSS] ANSI X9.57-199x, "Public Key Cryptography For The Financial [DSS] ANSI X9.57-199x, "Public Key Cryptography For The Financial
Services Industry: Certificate Management" (Working Draft), 21 June, Services Industry: Certificate Management" (Working Draft), 21 June,
1996. 1996.
[ESS] "Enhanced Security Services for S/MIME", Internet draft, draft-
ietf-smime-ess-*.txt.
[MD5] "The MD5 Message Digest Algorithm", RFC 1321 [MD5] "The MD5 Message Digest Algorithm", RFC 1321
[MIME-SPEC] The primary definition of MIME. "MIME Part 1: Format of [MIME-SPEC] The primary definition of MIME. "MIME Part 1: Format of
Internet Message Bodies", RFC 2045; "MIME Part 2: Media Types", RFC Internet Message Bodies", RFC 2045; "MIME Part 2: Media Types", RFC
2046; "MIME Part 3: Message Header Extensions for Non-ASCII Text", RFC 2046; "MIME Part 3: Message Header Extensions for Non-ASCII Text", RFC
2047; "MIME Part 4: Registration Procedures", RFC 2048; "MIME Part 5: 2047; "MIME Part 4: Registration Procedures", RFC 2048; "MIME Part 5:
Conformance Criteria and Examples", RFC 2049 Conformance Criteria and Examples", RFC 2049
[MIME-SECURE] "Security Multiparts for MIME: Multipart/Signed and [MIME-SECURE] "Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847 Multipart/Encrypted", RFC 1847
[MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119 Levels", RFC 2119
[PKCS-1] "PKCS #1: RSA Encryption", Internet Draft draft-hoffman-pkcs- [PKCS-1] "PKCS #1: RSA Encryption Version 1.5", RFC 2313
rsa-encrypt
[PKCS-7] "PKCS #7: Cryptographic Message Syntax", Internet Draft draft- [PKCS-7] "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315
hoffman-pkcs-crypt-msg
[RC2] "Description of the RC2 Encryption Algorithm", Internet Draft [RC2] "A Description of the RC2 (r) Encryption Algorithm", RFC 2268
draft-rivest-rc2desc
[SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard," National Institute [SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard," National Institute
of Standards and Technology, U.S. Department of Commerce, DRAFT, 31May of Standards and Technology, U.S. Department of Commerce, DRAFT, 31May
1994. 1994.
[SMIMEV2] "S/MIME Message Specification", Internet Draft draft-dusse- [SMIMEV2] "S/MIME Version 2 Message Specification", RFC 2311
smime-msg
C. Compatibility with Prior Practice in S/MIME
S/MIME was originally developed by RSA Data Security, Inc. Many
developers implemented S/MIME agents before this document was
published. All S/MIME receiving agents SHOULD make every attempt to
interoperate with these earlier implementations of S/MIME.
C.1 Early MIME Types
Some early implementations of S/MIME agents used the following MIME
types:
application/x-pkcs7-mime
application/x-pkcs7-signature
In each case, the "x-" subtypes correspond to the subtypes described
in this document without the "x-".
C.2 Profiles
Early S/MIME documentation had two profiles for encryption:
"restricted" and "unrestricted". The difference between these profiles
historically came about due to US Government export regulations, as
described at the end of this section. It is expected that in the
future, there will be few agents that only use the restricted profile.
Briefly, the restricted profile required the ability to encrypt and
decrypt using RSA's trade-secret RC2 algorithm in CBC mode with 40-bit
keys. The unrestricted profile required the ability to encrypt and
decrypt using RSA's trade-secret RC2 algorithm in CBC mode with 40-bit
keys, and to encrypt and decrypt using tripleDES. The restricted
profile also had non-mandatory suggestions for other algorithms, but
these were not widely implemented.
It is important to note that many current implementations of S/MIME
use the restricted profile.
C.2.1 Historical Reasons for the Existence of Two Encryption Profiles
Due to US Government export regulations, an S/MIME agent which
supports a strong content encryption algorithm such as DES would not
be freely exportable outside of North America. US software
manufacturers have been compelled to incorporate an exportable or
"restricted" content encryption algorithm in order to create a widely
exportable version of their product. S/MIME agents created in the US
and intended for US domestic use (or use under special State
Department export licenses) can utilize stronger, "unrestricted"
content encryption. However, in order to achieve interoperability,
such agents need to support whatever exportable algorithm is
incorporated in restricted S/MIME agents.
The RC2 symmetric encryption algorithm has been approved by the US
Government for "expedited" export licensing at certain key sizes.
Consequently, support for the RC2 algorithm in CBC mode is required
for baseline interoperability in all S/MIME implementations. Support
for other strong symmetric encryption algorithms such as RC5 CBC, DES
CBC and DES EDE3-CBC for content encryption is strongly encouraged
where possible.
D. Changes from S/MIME v2
Changed Section 2.1 to SHOULD instead of MUST support MD5.
Changed Section 2.2 to MUST support DSS for receiving and sending and
SHOULD support RSA for receiving and sending.
Changed Section 2.3 to MUST support Diffie-Hellman for receiving and
sending and SHOULD support RSA for receiving and sending.
Changed Section 2.6 to MUST support tripleDES for receiving and
sending and SHOULD support RC2/40 for receiving and sending.
Changed some references from [PKCS-7] to [CMS] and added [CMS].
Added Section 2.5.3, SMIMEEncryptionKeyPreference.
E. Request for New MIME Subtypes C. Request for New MIME Subtypes
E.1 application/pkcs7-mime C.1 application/pkcs7-mime
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkcs7-mime Subject: Registration of MIME media type application/pkcs7-mime
MIME media type name: application MIME media type name: application
MIME subtype name: pkcs7-mime MIME subtype name: pkcs7-mime
Required parameters: none Required parameters: none
skipping to change at line 1305 skipping to change at line 1248
Additional information: Additional information:
File extension(s): .p7m and .p7c File extension(s): .p7m and .p7c
Macintosh File Type Code(s): Macintosh File Type Code(s):
Person & email address to contact for further information: Steve Person & email address to contact for further information: Steve
Dusse, spock@rsa.com Dusse, spock@rsa.com
Intended usage: COMMON Intended usage: COMMON
E.2 application/pkcs7-signature C.2 application/pkcs7-signature
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkcs7-signature Subject: Registration of MIME media type application/pkcs7-signature
MIME media type name: application MIME media type name: application
MIME subtype name: pkcs7-signature MIME subtype name: pkcs7-signature
Required parameters: none Required parameters: none
skipping to change at line 1340 skipping to change at line 1283
Additional information: Additional information:
File extension(s): .p7s File extension(s): .p7s
Macintosh File Type Code(s): Macintosh File Type Code(s):
Person & email address to contact for further information: Steve Person & email address to contact for further information: Steve
Dusse, spock@rsa.com Dusse, spock@rsa.com
Intended usage: COMMON Intended usage: COMMON
F. Encapsulating Signed Messages for Internet Transport D. Encapsulating Signed Messages for Internet Transport
The rationale behind the multiple formats for signing has to do with The rationale behind the multiple formats for signing has to do with
the MIME subtype defaulting rules of the application and multipart top- the MIME subtype defaulting rules of the application and multipart top-
level types, and the behavior of currently deployed gateways and mail level types, and the behavior of currently deployed gateways and mail
user agents. user agents.
Ideally, the multipart/signed format would be the only format used Ideally, the multipart/signed format would be the only format used
because it provides a truly backwards compatible way to sign MIME because it provides a truly backwards compatible way to sign MIME
entities. In a pure MIME environment with very capable user agents, entities. In a pure MIME environment with very capable user agents,
this would be possible. The world, however, is more complex than this. this would be possible. The world, however, is more complex than this.
skipping to change at line 1376 skipping to change at line 1319
A similar problem occurs when an attempt is made to combine an A similar problem occurs when an attempt is made to combine an
existing user agent with a stand-alone S/MIME facility. Typical user existing user agent with a stand-alone S/MIME facility. Typical user
agents do not have the ability to make a multipart sub-entity agents do not have the ability to make a multipart sub-entity
available to a stand-alone application in the same way they make leaf available to a stand-alone application in the same way they make leaf
MIME entities available to "viewer" applications. This user agent MIME entities available to "viewer" applications. This user agent
behavior is not required by the MIME standard and thus not widely behavior is not required by the MIME standard and thus not widely
implemented. The result is that it is impossible for most user agents implemented. The result is that it is impossible for most user agents
to hand off the entire multipart/signed entity to a stand-alone to hand off the entire multipart/signed entity to a stand-alone
application. application.
F.1 Solutions to the Problem D.1 Solutions to the Problem
To work around these two problems, the application/pkcs7-mime type can To work around these two problems, the application/pkcs7-mime type can
be used. When going through a gateway, it will be defaulted to the be used. When going through a gateway, it will be defaulted to the
MIME type of application/octet-stream and treated as a single opaque MIME type of application/octet-stream and treated as a single opaque
entity. That is, the message will be treated as an attachment of entity. That is, the message will be treated as an attachment of
unknown type, converted into the local representation for an unknown type, converted into the local representation for an
attachment and thus can be made available to an S/MIME facility attachment and thus can be made available to an S/MIME facility
completely intact. A similar result is achieved when a user agent completely intact. A similar result is achieved when a user agent
similarly treats the application/pkcs7-mime MIME entity as a simple similarly treats the application/pkcs7-mime MIME entity as a simple
leaf node of the MIME structure and makes it available to viewer leaf node of the MIME structure and makes it available to viewer
skipping to change at line 1403 skipping to change at line 1346
gateway that does not recognize it, its type will be defaulted to gateway that does not recognize it, its type will be defaulted to
application/octet-stream and it will be treated as a single opaque application/octet-stream and it will be treated as a single opaque
entity. A similar situation will happen with a receiving client that entity. A similar situation will happen with a receiving client that
does not recognize the entity. It will usually be treated as a file does not recognize the entity. It will usually be treated as a file
attachment. It can then be made available to the S/MIME facility. attachment. It can then be made available to the S/MIME facility.
The major difference between the two alternatives (application/pkcs7- The major difference between the two alternatives (application/pkcs7-
mime or multipart/signed wrapped with application/mime ) is when the mime or multipart/signed wrapped with application/mime ) is when the
S/MIME facility opens the attachment. In the latter case, the S/MIME S/MIME facility opens the attachment. In the latter case, the S/MIME
agent will find a multipart/signed entity rather than a BER encoded agent will find a multipart/signed entity rather than a BER encoded
PKCS7-object. Considering the two representations abstractly, the only CMS object. Considering the two representations abstractly, the only
difference is syntax. difference is syntax.
Application/mime is a general mechanism for encapsulating MIME, and in Application/mime is a general mechanism for encapsulating MIME, and in
particular delaying its interpretation until it can be done in the particular delaying its interpretation until it can be done in the
appropriate environment or at the request of the user. The appropriate environment or at the request of the user. The
application/mime specification does not permit a user agent to application/mime specification does not permit a user agent to
automatically interpret the encapsulated MIME unless it can be automatically interpret the encapsulated MIME unless it can be
processed entirely and properly. The parameters to the processed entirely and properly. The parameters to the
application/mime entity give the type of the encapsulated entity so it application/mime entity give the type of the encapsulated entity so it
can be determined whether or not the entity can be processed before it can be determined whether or not the entity can be processed before it
skipping to change at line 1427 skipping to change at line 1370
built into a gateway or user agent, allowing expansion of the built into a gateway or user agent, allowing expansion of the
encapsulated entity under user control. Because it is a general encapsulated entity under user control. Because it is a general
mechanism, it is in many cases more likely to be available than an mechanism, it is in many cases more likely to be available than an
S/MIME facility. Thus, it enables users to expand or to verify signed S/MIME facility. Thus, it enables users to expand or to verify signed
messages based on their local facilities and choices. It provides messages based on their local facilities and choices. It provides
exactly the same advantages that the application/pkcs7-mime with exactly the same advantages that the application/pkcs7-mime with
signedData does. It also has the added benefit of allowing expansion signedData does. It also has the added benefit of allowing expansion
in non-S/MIME environments and expansion under the recipient's in non-S/MIME environments and expansion under the recipient's
control. control.
F.2 Encapsulation Using application/mime D.2 Encapsulation Using application/mime
In some cases, multipart/signed entities are automatically decomposed In some cases, multipart/signed entities are automatically decomposed
in such a way as to make computing the hash of the first part, the in such a way as to make computing the hash of the first part, the
signed part, impossible; in such a situation, the signature becomes signed part, impossible; in such a situation, the signature becomes
unverifiable. In order to prevent such decomposition until the MIME unverifiable. In order to prevent such decomposition until the MIME
entity can be processed in a proper S/MIME environment, a entity can be processed in a proper S/MIME environment, a
multipart/signed entity may be encapsulated in an application/mime multipart/signed entity may be encapsulated in an application/mime
entity. entity.
All S/MIME implementations SHOULD be able to generate and receive All S/MIME implementations SHOULD be able to generate and receive
skipping to change at line 1505 skipping to change at line 1448
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s Content-Disposition: attachment; filename=smime.p7s
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756 7GhIGfHfYT64VQbnj756
--boundary42-- --boundary42--
F.3 Encapsulation in an Non-MIME Environment D.3 Encapsulation in an Non-MIME Environment
While this document primarily addresses the Internet, it is useful to While this document primarily addresses the Internet, it is useful to
compose and receive S/MIME secured messages in non-MIME environments. compose and receive S/MIME secured messages in non-MIME environments.
This is particularly the case when it is desired that security be This is particularly the case when it is desired that security be
implemented end-to-end. Other discussion here addresses the receipt of implemented end-to-end. Other discussion here addresses the receipt of
S/MIME messages in non-MIME environments. Here the composition of S/MIME messages in non-MIME environments. Here the composition of
multipart/signed entities is addressed. multipart/signed entities is addressed.
When a message is to be sent in such an environment, the When a message is to be sent in such an environment, the
multipart/signed entity is created as described above. That entity is multipart/signed entity is created as described above. That entity is
skipping to change at line 1527 skipping to change at line 1470
an attachment. It must have a file name that ends with ".aps", as this an attachment. It must have a file name that ends with ".aps", as this
is the sole mechanism for recognizing it as an S/MIME message by the is the sole mechanism for recognizing it as an S/MIME message by the
receiving agent. receiving agent.
When this message arrives in a MIME environment, it is likely to have When this message arrives in a MIME environment, it is likely to have
a MIME type of application/octet-stream, with MIME parameters giving a MIME type of application/octet-stream, with MIME parameters giving
the filename for the attachment. If the intervening gateway has the filename for the attachment. If the intervening gateway has
carried the file type, it will end in ".aps" and be recognized as an carried the file type, it will end in ".aps" and be recognized as an
S/MIME message. S/MIME message.
G. Acknowledgements E. Acknowledgements
This document is largely derived from [SMIMEV2] written by Steve This document is largely derived from [SMIMEV2] written by Steve
Dusse, Paul Hoffman, Blake Ramsdell, Laurence Lundblade, and Lisa Dusse, Paul Hoffman, Blake Ramsdell, Laurence Lundblade, and Lisa
Repka. Repka.
Significant comments and additions were made by John Pawling and Jim Significant comments and additions were made by John Pawling and Jim
Schaad. Schaad.
H. Needed changes F. Needed changes
We need to document Diffie-Hellman parameters (key lengths, etc.) --
is this a separate draft?
Section A cleanup (SMIMECapabilities and SMIMEEncryptionKeyPreference
in their own sections?)
Should SMIMEEncryptionKeyPreference simply be IssuerAndSerialNumber?
ASN.1 issues -- syntax, CCITT vs. ITU-T in section 1.3, OID cleanup
Section 1.1 -- what documents are needed to implement S/MIME. Should Section 1.1 -- what documents are needed to implement S/MIME. Should
probably include X9.42, X9.57, etc. probably include X9.42, X9.57, etc.
Should we refer to draft-freed-gatesec in section 3.1.3 or elsewhere? Should we refer to draft-freed-gatesec in section 3.1.3 or elsewhere?
Section 2.6.1.x -- I want to discuss this some more.
Add a section for selecting the encrypting certificate for a
particular recipient (doesn't belong in 2.6)
SMIMEEncryptionKeyPreference -- what implication do current
discussions have about this?
smimeVersion capability?
Section 4.1 -- keylengths for non-RSA keypair generation language
needed.
I. Changes from last draft G. Changes from last draft
Fixed language in 2.6.2.4 regarding RC2/40 for "Unknown Capabilities, Fixed section 2.6 numbering (Jim Schaad)
No Risk of Failed Decryption" (John Pawling) Sending agents MUST SHA-1 (used to be SHOULD) (John Pawling)
Various ASN.1 fixes (Phil Griffin) Redid 2.4.1 (use of id-data) (John Pawling)
Removed all PKCS #10 / certificate request references (Paul Hoffman) Removed SHOULD implication for encryption key preference (Jim Schaad)
Fixed some PKCS references that needed to be CMS (John Pawling) Clarified language regarding year interpretation in signing-time (John
3.7 is now Registration Requests (Paul Hoffman / Dave Crocker)
Clarified section 2.3 text regarding RSA public modulus length (John
Pawling)
Added text to 3.3 regarding encryption of content encryption key for
the originator (John Pawling)
Changed section 2.2 title to SignatureAlgorithmIdentifier (John
Pawling) Pawling)
Removed willywaggling text in 2.6 (Paul Hoffman)
PKCS to CMS changes (John Pawling)
Clarification in section 3.2 (John Pawling, Jim Schaad)
Various "and SignedData" to "with SignedData" changes (John Pawling)
Various terminology clarifications (John Pawling)
micalg language cleanup for multiple digests in 3.4.3.2 (Jim Schaad)
Removed editorial language about v2 from 3.7 (John Pawling)
Fixed references for [PKCS-1], [PKCS-7] and [RC2] to point to RFCs
(Blake Ramsdell)
Updated other references (John Pawling)
Removed appendix (that's funny) D (John Pawling)
J. Editor's address H. Editor's address
Blake Ramsdell Blake Ramsdell
Worldtalk Worldtalk
13122 NE 20th St., Suite C 13122 NE 20th St., Suite C
Bellevue, WA 98005 Bellevue, WA 98005
(425) 882-8861 (425) 882-8861
blaker@deming.com blaker@deming.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/