draft-ietf-smime-rfc2633bis-03.txt   draft-ietf-smime-rfc2633bis-04.txt 
Internet Draft Editor: Blake Ramsdell, Internet Draft Editor: Blake Ramsdell,
draft-ietf-smime-rfc2633bis-03.txt Brute Squad Labs draft-ietf-smime-rfc2633bis-04.txt Brute Squad Labs
January 16, 2003 June 2, 2003
Expires July 16, 2003 Expires December 2, 2003
S/MIME Version 3.1 Message Specification S/MIME Version 3.1 Message Specification
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
skipping to change at line 69 skipping to change at line 69
derived from PKCS #7 [PKCS-7]. This specification also defines the derived from PKCS #7 [PKCS-7]. This specification also defines the
application/pkcs7- mime MIME type that can be used to transport those application/pkcs7- mime MIME type that can be used to transport those
body parts. body parts.
This specification also discusses how to use the multipart/signed MIME This specification also discusses how to use the multipart/signed MIME
type defined in [MIME-SECURE] to transport S/MIME signed messages. type defined in [MIME-SECURE] to transport S/MIME signed messages.
multipart/signed is used in conjunction with the multipart/signed is used in conjunction with the
application/pkcs7-signature MIME type, which is used to transport application/pkcs7-signature MIME type, which is used to transport
a detached S/MIME signature. a detached S/MIME signature.
In order to create S/MIME messages, an S/MIME agent has to follow the In order to create S/MIME messages, an S/MIME agent MUST follow the
specifications in this document, as well as the specifications specifications in this document, as well as the specifications
listed in the Cryptographic Message Syntax [CMS]. listed in the Cryptographic Message Syntax [CMS].
Throughout this specification, there are requirements and Throughout this specification, there are requirements and
recommendations made for how receiving agents handle incoming recommendations made for how receiving agents handle incoming
messages. There are separate requirements and recommendations for how messages. There are separate requirements and recommendations for how
sending agents create outgoing messages. In general, the best strategy sending agents create outgoing messages. In general, the best strategy
is to "be liberal in what you receive and conservative in what you is to "be liberal in what you receive and conservative in what you
send". Most of the requirements are placed on the handling of incoming send". Most of the requirements are placed on the handling of incoming
messages while the recommendations are mostly on the creation of messages while the recommendations are mostly on the creation of
skipping to change at line 102 skipping to change at line 102
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [MUSTSHOULD]. document are to be interpreted as described in [MUSTSHOULD].
1.3 Definitions 1.3 Definitions
For the purposes of this specification, the following definitions For the purposes of this specification, the following definitions
apply. apply.
ASN.1: Abstract Syntax Notation One, as defined in CCITT X.208. ASN.1: Abstract Syntax Notation One, as defined in CCITT X.208
[X.208-88].
BER: Basic Encoding Rules for ASN.1, as defined in CCITT X.209. BER: Basic Encoding Rules for ASN.1, as defined in CCITT X.209
[X.209-88].
Certificate: A type that binds an entity's distinguished name to a Certificate: A type that binds an entity's distinguished name to a
public key with a digital signature. public key with a digital signature.
DER: Distinguished Encoding Rules for ASN.1, as defined in CCITT DER: Distinguished Encoding Rules for ASN.1, as defined in CCITT
X.509. X.509 [X.509-88].
7-bit data: Text data with lines less than 998 characters long, where 7-bit data: Text data with lines less than 998 characters long, where
none of the characters have the 8th bit set, and there are no NULL none of the characters have the 8th bit set, and there are no NULL
characters. <CR> and <LF> occur only as part of a <CR><LF> end of line characters. <CR> and <LF> occur only as part of a <CR><LF> end of line
delimiter. delimiter.
8-bit data: Text data with lines less than 998 characters, and where 8-bit data: Text data with lines less than 998 characters, and where
none of the characters are NULL characters. <CR> and <LF> occur only none of the characters are NULL characters. <CR> and <LF> occur only
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.
Receiving agent: software that interprets and processes S/MIME CMS Receiving agent: software that interprets and processes S/MIME CMS
objects, MIME body parts that contain CMS objects, or both. objects, MIME body parts that contain CMS content types, or both.
Sending agent: software that creates S/MIME CMS objects, MIME body Sending agent: software that creates S/MIME CMS content types, MIME
parts that contain CMS objects, or both. body parts that contain CMS content types, or both.
S/MIME agent: user software that is a receiving agent, a sending S/MIME agent: user software that is a receiving agent, a sending
agent, or both. agent, or both.
1.4 Compatibility with Prior Practice of S/MIME 1.4 Compatibility with Prior Practice of S/MIME
S/MIME version 3 agents should attempt to have the greatest S/MIME version 3 agents should attempt to have the greatest
interoperability possible with S/MIME version 2 agents. S/MIME version interoperability possible with S/MIME version 2 agents. S/MIME version
2 is described in RFC 2311 through RFC 2315, inclusive. RFC 2311 also 2 is described in RFC 2311 through RFC 2315, inclusive. RFC 2311 also
has historical information about the development of S/MIME. has historical information about the development of S/MIME.
skipping to change at line 222 skipping to change at line 224
[CMSALG]. [CMSALG].
Note that S/MIME v3 clients might only implement key encryption and Note that S/MIME v3 clients might only implement key encryption and
decryption using the Diffie-Hellman algorithm. Also note that S/MIME decryption using the Diffie-Hellman algorithm. Also note that S/MIME
v2 clients are only capable of decrypting content-encryption keys v2 clients are only capable of decrypting content-encryption keys
using the rsaEncryption algorithm. using the rsaEncryption algorithm.
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, EnvelopedData and CompressedData content types are
S/MIME. currently used for S/MIME.
2.4.1 Data Content Type 2.4.1 Data Content Type
Sending agents MUST use the id-data content type identifier to Sending agents MUST use the id-data content type identifier to
identify the "inner" MIME message content. For example, when applying identify the "inner" MIME message content. For example, when applying
a digital signature to MIME data, the CMS signedData encapContentInfo a digital signature to MIME data, the CMS signedData encapContentInfo
eContentType MUST include the id-data object identifier and the MIME eContentType MUST include the id-data object identifier and the MIME
content MUST be stored in the SignedData encapContentInfo eContent content MUST be stored in the SignedData encapContentInfo eContent
OCTET STRING (unless the sending agent is using multipart/signed, in OCTET STRING (unless the sending agent is using multipart/signed, in
which case the eContent is absent, per section 3.4.3 of this which case the eContent is absent, per section 3.4.3 of this
skipping to change at line 253 skipping to change at line 255
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 data confidentiality to a message. This content type is used to apply data confidentiality to a message.
A sender needs to have access to a public key for each intended A sender needs to have access to a public key for each intended
message recipient to use this service. This content type does not message recipient to use this service. This content type does not
provide authentication. provide authentication.
2.4.4 CompressedData Content Type
This content type is used to apply data compression to a message. This
content type does not provide authentication or privacy, and is only
used to reduce message size.
2.5 Attribute SignerInfo Type 2.5 Attribute SignerInfo Type
The SignerInfo type allows the inclusion of unsigned and signed The SignerInfo type allows the inclusion of unsigned and signed
attributes to be included along with a signature. 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 listed here. Sending agents SHOULD generate of the signed attributes listed here. Sending agents SHOULD generate
one instance of each of the following signed attributes in each S/MIME one instance of each of the following signed attributes in each S/MIME
message: message:
- signingTime (section 2.5.1 in this document) - signingTime (section 2.5.1 in this document)
- sMIMECapabilities (section 2.5.2 in this document) - sMIMECapabilities (section 2.5.2 in this document)
- sMIMEEncryptionKeyPreference (section 2.5.3 in this document) - sMIMEEncryptionKeyPreference (section 2.5.3 in this document)
- id-messageDigest (section 11.2 in [CMS])
- id-contentType (section 11.1 in [CMS])
Further, receiving agents SHOULD be able to handle zero or one Further, receiving agents SHOULD be able to handle zero or one
instance in the signed attributes of the signingCertificate attribute instance in the signingCertificate signed attribute, as defined in
(section 5 in [ESS]). section 5 of [ESS].
Sending agents SHOULD generate one instance of the signingCertificate Sending agents SHOULD generate one instance of the signingCertificate
signed attribute in each S/MIME message. signed attribute in each S/MIME message.
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.
Sending agents that include signed attributes that are not listed here Interactive sending agents that include signed attributes that are not
SHOULD display those attributes to the user, so that the user is aware listed here SHOULD display those attributes to the user, so that the
of all of the data being signed. user is aware of all of the data being signed.
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. The time of signing will most likely be created by a was signed. The time of signing will most likely be created by a
message originator and therefore is only as trustworthy as the message originator and therefore is only as trustworthy as the
originator. 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
skipping to change at line 323 skipping to change at line 333
defines the ASN.1 syntax for Attribute to include attrValues SET OF defines the ASN.1 syntax for Attribute to include attrValues SET OF
AttributeValue. A SMIMECapabilities attribute MUST only include a AttributeValue. A SMIMECapabilities attribute MUST only include a
single instance of AttributeValue. There MUST NOT be zero or multiple single instance of AttributeValue. There MUST NOT be zero or multiple
instances of AttributeValue present in the attrValues SET OF instances of AttributeValue present in the attrValues SET OF
AttributeValue. AttributeValue.
The semantics of the SMIMECapabilites attribute specify a partial list The semantics of the SMIMECapabilites attribute specify a partial list
as to what the client announcing the SMIMECapabilites can support. A as to what the client announcing the SMIMECapabilites can support. A
client does not have to list every capability it supports, and client does not have to list every capability it supports, and
probably should not list all its capabilities so that the capabilities probably should not list all its capabilities so that the capabilities
list doesn't get too long. In an SMIMECapabilities attribute, the OIDs list doesn't get too long. In an SMIMECapabilities attribute, the
are listed in order of their preference, but SHOULD be logically object identifiers (OIDs) are listed in order of their preference, but
separated along the lines of their categories (signature algorithms, SHOULD be logically separated along the lines of their categories
symmetric algorithms, key encipherment algorithms, etc.) (signature algorithms, symmetric algorithms, key encipherment
algorithms, etc.)
The structure of the SMIMECapabilities attribute is to facilitate The structure of the SMIMECapabilities attribute is to facilitate
simple table lookups and binary comparisons in order to determine simple table lookups and binary comparisons in order to determine
matches. For instance, the DER-encoding for the SMIMECapability for matches. For instance, the DER-encoding for the SMIMECapability for
DES EDE3 CBC MUST be identically encoded regardless of the DES EDE3 CBC MUST be identically encoded regardless of the
implementation. implementation.
In the case of symmetric algorithms, the associated parameters for the In the case of symmetric algorithms, the associated parameters for the
OID MUST specify all of the parameters necessary to differentiate OID MUST specify all of the parameters necessary to differentiate
between two instances of the same algorithm. For instance, the number between two instances of the same algorithm. For instance, the number
of rounds and block size for RC5 must be specified in addition to the of rounds and block size for RC5 must be specified in addition to the
key length. key length.
There is a list of OIDs (OIDs Used with S/MIME) that is centrally The OIDs used with S/MIME are assigned in several different RFCs. Note
maintained and is separate from this specification. The list of OIDs that all OIDs associated with the MUST and SHOULD implement algorithms
is maintained by the Internet Mail Consortium at are included in section A of this document.
<http://www.imc.org/ietf-smime/oids.html>. Note that all OIDs
associated with the MUST and SHOULD implement algorithms are included
in section A of this document.
The OIDs that correspond to algorithms SHOULD use the same OID as the The OIDs that correspond to algorithms SHOULD use the same OID as the
actual algorithm, except in the case where the algorithm usage is actual algorithm, except in the case where the algorithm usage is
ambiguous from the OID. For instance, in an earlier specification, ambiguous from the OID. For instance, in an earlier specification,
rsaEncryption was ambiguous because it could refer to either a rsaEncryption was ambiguous because it could refer to either a
signature algorithm or a key encipherment algorithm. In the event that signature algorithm or a key encipherment algorithm. In the event that
an OID is ambiguous, it needs to be arbitrated by the maintainer of an OID is ambiguous, it needs to be arbitrated by the maintainer of
the registered SMIMECapabilities list as to which type of algorithm the registered SMIMECapabilities list as to which type of algorithm
will use the OID, and a new OID MUST be allocated under the will use the OID, and a new OID MUST be allocated under the
smimeCapabilities OID to satisfy the other use of the OID. smimeCapabilities OID to satisfy the other use of the OID.
skipping to change at line 430 skipping to change at line 438
used for key management. used for key management.
- Or use some other method of determining the user's key management - Or use some other method of determining the user's key management
key. If a X.509 key management certificate is not found, then key. If a X.509 key management certificate is not found, then
encryption cannot be done with the signer of the message. If encryption cannot be done with the signer of the message. If
multiple X.509 key management certificates are found, the S/MIME multiple X.509 key management certificates are found, the S/MIME
agent can make an arbitrary choice between them. agent can make an arbitrary choice between them.
2.6 SignerIdentifier SignerInfo Type 2.6 SignerIdentifier SignerInfo Type
S/MIME v3 requires the use of SignerInfo version 1, that is the S/MIME v3.1 and S/MIME v3 requires the use of SignerInfo version 1,
issuerAndSerialNumber CHOICE MUST be used for SignerIdentifier. that is the issuerAndSerialNumber CHOICE MUST be used for
SignerIdentifier.
2.7 ContentEncryptionAlgorithmIdentifier 2.7 ContentEncryptionAlgorithmIdentifier
Sending and receiving agents MUST support encryption and decryption Sending and receiving agents MUST support encryption and decryption
with DES EDE3 CBC, hereinafter called "tripleDES" [CMSALG]. Receiving with DES EDE3 CBC, hereinafter called "tripleDES" [CMSALG]. Receiving
agents SHOULD support encryption and decryption using the RC2 [CMSALG] agents SHOULD support encryption and decryption using the RC2 [CMSALG]
or a compatible algorithm at a key size of 40 bits, hereinafter called or a compatible algorithm at a key size of 40 bits, hereinafter called
"RC2/40". "RC2/40".
2.7.1 Deciding Which Encryption Method To Use 2.7.1 Deciding Which Encryption Method To Use
skipping to change at line 500 skipping to change at line 509
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.7.1.2 Rule 2: Unknown Capabilities, Known Use of Encryption 2.7.1.2 Rule 2: Unknown Capabilities, Known Use of Encryption
If: If the following three conditions are met:
- 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.7.1.3 Rule 3: Unknown Capabilities, Unknown Version of S/MIME 2.7.1.3 Rule 3: Unknown Capabilities, Unknown Version of S/MIME
If: If the following two conditions are met:
- 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 no knowledge of the version of S/MIME - and the sending agent has no knowledge of the version of S/MIME
of the recipient, of the recipient,
then the sending agent SHOULD use tripleDES because it is a stronger then the sending agent SHOULD use tripleDES because it is a stronger
algorithm and is required by S/MIME v3. If the sending agent chooses algorithm and is required by S/MIME v3. If the sending agent chooses
not to use tripleDES in this step, it SHOULD use RC2/40. not to use tripleDES in this step, it SHOULD use RC2/40.
2.7.2 Choosing Weak Encryption 2.7.2 Choosing Weak Encryption
skipping to change at line 547 skipping to change at line 556
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 may be able to learn the contents of the communications channel may be able to learn the contents of the
strongly-encrypted message simply by decrypting the weakly-encrypted strongly-encrypted message simply by decrypting the weakly-encrypted
message. 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. content types. Several MIME types as well as several CMS content types
The data to be secured is always a canonical MIME entity. The MIME are used. The data to be secured is always a canonical MIME entity.
entity and other data, such as certificates and algorithm identifiers, The MIME entity and other data, such as certificates and algorithm
are given to CMS processing facilities which produces a CMS object. identifiers, are given to CMS processing facilities which produces a
The CMS object is then finally wrapped in MIME. The Enhanced Security CMS object. The CMS object is then finally wrapped in MIME. The
Services for S/MIME [ESS] document provides examples of how nested, Enhanced Security Services for S/MIME [ESS] document provides examples
secured S/MIME messages are formatted. ESS provides an example of how of how nested, secured S/MIME messages are formatted. ESS provides an
a triple-wrapped S/MIME message is formatted using multipart/signed example of how a triple-wrapped S/MIME message is formatted using
and application/pkcs7-mime for the signatures. 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].
3.1 Preparing the MIME Entity for Signing or Enveloping 3.1 Preparing the MIME Entity for Signing or Enveloping
S/MIME is used to secure MIME entities. A MIME entity may be a sub- S/MIME is used to secure MIME entities. A MIME entity may be a sub-
part, sub-parts of a message, or the whole message with all its sub- part, sub-parts of a message, or the whole message with all its sub-
parts. A MIME entity that is the whole message includes only the MIME parts. A MIME entity that is the whole message includes only the MIME
headers and MIME body, and does not include the RFC-822 headers. Note headers and MIME body, and does not include the RFC-822 headers. Note
that S/MIME can also be used to secure MIME entities used in that S/MIME can also be used to secure MIME entities used in
applications other than Internet mail. applications other than Internet mail. If protection of the RFC-822
headers is required, the use of the message/rfc822 MIME type is
explained later in this section.
The MIME entity that is secured and described in this section can be The MIME entity that is secured and described in this section can be
thought of as the "inside" MIME entity. That is, it is the "innermost" thought of as the "inside" MIME entity. That is, it is the "innermost"
object in what is possibly a larger MIME message. Processing "outside" object in what is possibly a larger MIME message. Processing "outside"
MIME entities into CMS objects is described in Section 3.2, 3.4 and MIME entities into CMS content types is described in Section 3.2, 3.4
elsewhere. and elsewhere.
The procedure for preparing a MIME entity is given in [MIME-SPEC]. The The procedure for preparing a MIME entity is given in [MIME-SPEC]. The
same procedure is used here with some additional restrictions when same procedure is used here with some additional restrictions when
signing. Description of the procedures from [MIME-SPEC] are repeated signing. Description of the procedures from [MIME-SPEC] are repeated
here, but the reader should refer to that document for the exact here, but the reader should refer to that document for the exact
procedure. This section also describes additional requirements. procedure. This section also describes additional requirements.
A single procedure is used for creating MIME entities that are to be A single procedure is used for creating MIME entities that are to be
signed, enveloped, or both signed and enveloped. Some additional steps signed, enveloped, or both signed and enveloped. Some additional steps
are recommended to defend against known corruptions that can occur are recommended to defend against known corruptions that can occur
skipping to change at line 686 skipping to change at line 697
id-cap-preferBinaryInside sMIMECapabilities attribute, by prior id-cap-preferBinaryInside sMIMECapabilities attribute, by prior
agreement, or by other means. agreement, or by other means.
If one or more intended recipients are unable to handle inner binary If one or more intended recipients are unable to handle inner binary
MIME objects, or if this capability in unknown for any of the intended MIME objects, or if this capability in unknown for any of the intended
recipients, S/MIME implementations SHOULD use transfer encoding recipients, S/MIME implementations SHOULD use transfer encoding
described in section 3.1.3 for all MIME entities they secure. described in section 3.1.3 for all MIME entities they secure.
3.1.3 Transfer Encoding for Signing Using multipart/signed 3.1.3 Transfer Encoding for Signing Using multipart/signed
If a multipart/signed entity is EVER to be transmitted over the If a multipart/signed entity is ever to be transmitted over the
standard Internet SMTP infrastructure or other transport that is standard Internet SMTP infrastructure or other transport that is
constrained to 7-bit text, it MUST have transfer encoding applied so constrained to 7-bit text, it MUST have transfer encoding applied so
that it is represented as 7-bit text. MIME entities that are 7-bit that it is represented as 7-bit text. MIME entities that are 7-bit
data already need no transfer encoding. Entities such as 8-bit text data already need no transfer encoding. Entities such as 8-bit text
and binary data can be encoded with quoted-printable or base-64 and binary data can be encoded with quoted-printable or base-64
transfer encoding. transfer encoding.
The primary reason for the 7-bit requirement is that the Internet mail The primary reason for the 7-bit requirement is that the Internet mail
transport infrastructure cannot guarantee transport of 8-bit or binary transport infrastructure cannot guarantee transport of 8-bit or binary
data. Even though many segments of the transport infrastructure now data. Even though many segments of the transport infrastructure now
skipping to change at line 759 skipping to change at line 770
iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC// iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
HOxEa44b+EI= HOxEa44b+EI=
--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 content types
several types including envelopedData and signedData. The details of including envelopedData, signedData and compressedData. 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 section describes the general characteristics of the
application/pkcs7- mime type. application/pkcs7- mime type.
The carried CMS object always contains a MIME entity that is prepared The carried CMS object always contains a MIME entity that is prepared
as described in section 3.1 if the eContentType is id-data. Other as described in section 3.1 if the eContentType is id-data. Other
contents may be carried when the eContentType contains different contents may be carried when the eContentType contains different
values. See [ESS] for an example of this with signed receipts. values. See [ESS] for an example of this with signed receipts.
Since CMS objects are binary data, in most cases base-64 transfer Since CMS content types are binary data, in most cases base-64
encoding is appropriate, in particular when used with SMTP transport. transfer encoding is appropriate, in particular when used with SMTP
The transfer encoding used depends on the transport through which the transport. The transfer encoding used depends on the transport through
object is to be sent, and is not a characteristic of the MIME type. which the 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.
Because there are several types of application/pkcs7-mime objects, a Because there are several types of application/pkcs7-mime objects, a
sending agent SHOULD do as much as possible to help a receiving agent sending agent SHOULD do as much as possible to help a receiving agent
know about the contents of the object without forcing the receiving know about the contents of the object without forcing the receiving
agent to decode the ASN.1 for the object. The MIME headers of all agent to decode the ASN.1 for the object. The MIME headers of all
skipping to change at line 1021 skipping to change at line 1033
the message digest algorithm(s) used in the calculation of the Message the message digest algorithm(s) used in the calculation of the Message
Integrity Check. If multiple message digest algorithms are used they Integrity Check. If multiple message digest algorithms are used they
MUST be separated by commas per [MIME-SECURE]. The values to be placed MUST be separated by commas per [MIME-SECURE]. The values to be placed
in the micalg parameter SHOULD be from the following: 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
SHA-256 sha256
SHA-384 sha384
SHA-512 sha512
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
agents SHOULD be able to recover gracefully from a micalg parameter agents SHOULD be able to recover gracefully from a micalg parameter
value that they do not recognize. value that they do not recognize.
The SHA-256, SHA-384 and SHA-512 algorithms [FIPS180-2] are not
currently supported in S/MIME, and are included here for completeness.
3.4.3.3 Sample multipart/signed Message 3.4.3.3 Sample multipart/signed Message
Content-Type: multipart/signed; Content-Type: multipart/signed;
protocol="application/pkcs7-signature"; protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42 micalg=sha1; boundary=boundary42
--boundary42 --boundary42
Content-Type: text/plain Content-Type: text/plain
This is a clear-signed message. This is a clear-signed message.
skipping to change at line 1088 skipping to change at line 1106
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7z Content-Disposition: attachment; filename=smime.p7z
rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
0GhIGfHfQbnj756YT64V 0GhIGfHfQbnj756YT64V
3.6 Multiple Operations 3.6 Multiple Operations
Any of the signed-only, compressed-only and encrypted-only MIME The signed-only, encrypted-only, and compressed-only MIME formats can
formats listed above may be nested. This is allowed because the above be nested. This works because these formats are all MIME entities that
formats are all MIME entities, and because they all encapsulate MIME encapsulate other MIME entities.
entities.
An S/MIME implementation MUST be able to receive and process An S/MIME implementation MUST be able to receive and process
arbitrarily nested S/MIME within reasonable resource limits of the arbitrarily nested S/MIME within reasonable resource limits of the
recipient computer. recipient computer.
It is possible to apply any of the signing, encrypting and compressing It is possible to apply any of the signing, encrypting and compressing
operations in any order. It is up to the implementor and the user to operations in any order. It is up to the implementor and the user to
choose. When signing first, the signatories are then securely obscured choose. When signing first, the signatories are then securely obscured
by the enveloping. When enveloping first the signatories are exposed, by the enveloping. When enveloping first the signatories are exposed,
but it is possible to verify signatures without removing the but it is possible to verify signatures without removing the
skipping to change at line 1153 skipping to change at line 1170
3.8 Registration Requests 3.8 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
signature so that a receiving agent can verify the signature. There signature so that a receiving agent can verify the signature. There
are many ways of getting certificates, such as through an exchange are many ways of getting certificates, such as through an exchange
with a certificate authority, through a hardware token or diskette, with a certificate authority, through a hardware token or diskette,
and so on. and so on.
S/MIME v2 [SMIMEV2] specified a method for "registering" public keys S/MIME v2 [SMIMEV2] specified a method for "registering" public keys
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 Since that time, the IETF PKIX Working Group has developed other
requesting certificates; however, that work was not finished at the methods for requesting certificates. However, S/MIME v3.1 does not
time of this specification. S/MIME v3 does not specify how to request require a particular certificate request mechanism.
a certificate, but instead mandates that every sending agent already
has a certificate. Standardization of certificate management is being
pursued separately in the IETF.
3.9 Identifying an S/MIME Message 3.9 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 of the criteria listed below.
The file suffix in the table below comes from the "name" parameter in The file suffix in the table below comes from the "name" parameter in
the content-type header, or the "filename" parameter on the content- the content-type header, or the "filename" parameter on the content-
disposition header. These parameters that give the file suffix are not disposition header. These parameters that give the file suffix are not
listed below as part of the parameter section. listed below as part of the parameter section.
MIME type: application/pkcs7-mime MIME type: application/pkcs7-mime
parameters: any parameters: any
file suffix: any file suffix: any
skipping to change at line 1371 skipping to change at line 1385
Syntax (CMS)", RFC 3274 Syntax (CMS)", RFC 3274
[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
[DHSUB] "Methods for Avoiding the "Small-Subgroup" Attacks on the [DHSUB] "Methods for Avoiding the "Small-Subgroup" Attacks on the
Diffie-Hellman Key Agreement Method for S/MIME", RFC 2785 Diffie-Hellman Key Agreement Method for S/MIME", RFC 2785
[ESS] "Enhanced Security Services for S/MIME", RFC 2634 [ESS] "Enhanced Security Services for S/MIME", RFC 2634
[FIPS180-2] "Secure Hash Signature Standard (SHS)", National Institute
of Standards and Technology (NIST). FIPS Publication 180-2
[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
[MMA] "Preventing the Million Message Attack on CMS", RFC 3218 [MMA] "Preventing the Million Message Attack on CMS", RFC 3218
[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-7] "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315 [PKCS-7] "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315
[RANDOM] "Randomness Recommendations for Security", RFC 1750 [RANDOM] "Randomness Recommendations for Security", RFC 1750
[SMIMEV2] "S/MIME Version 2 Message Specification", RFC 2311 [SMIMEV2] "S/MIME Version 2 Message Specification", RFC 2311
[X.208-88] CCITT. Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1). 1988.
[X.209-88] CCITT. Recommendation X.209: Specification of Basic
Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988.
[X.509-88] CCITT. Recommendation X.509: The Directory - Authentication
Framework. 1988.
C. Acknowledgements C. Acknowledgements
Many thanks go out to the other authors of the S/MIME Version 2 Many thanks go out to the other authors of the S/MIME Version 2
Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence
Lundblade and Lisa Repka. Lundblade and Lisa Repka.
A number of the members of the S/MIME Working Group have also worked A number of the members of the S/MIME Working Group have also worked
very hard and contributed to this document. Any list of people is very hard and contributed to this document. Any list of people is
doomed to omission, and for that I apologize. In alphabetical order, doomed to omission, and for that I apologize. In alphabetical order,
the following people stand out in my mind due to the fact that they the following people stand out in my mind due to the fact that they
skipping to change at line 1425 skipping to change at line 1451
Blake Ramsdell Blake Ramsdell
Brute Squad Labs Brute Squad Labs
Suite 217-C Suite 217-C
16451 Redmond Way 16451 Redmond Way
Redmond, WA 98052-4482 Redmond, WA 98052-4482
blake@brutesquadlabs.com blake@brutesquadlabs.com
E. Changes from last draft E. Changes from last draft
English fixes (Jim Schaad) Several fixes from Russ Housley
http://www.imc.org/ietf-smime/mail-archive/msg01461.html
Compression guidance (Jim Schaad) (Russ Housley)
MMA language taken verbatim from [CMSALG] (Blake Ramsdell, Russ
Housley)
Small subgroup Diffie Hellman taken verbatim from [DHSUB] (Blake
Ramsdell, R. Zuccherato)
Module ID changes (Jim Schaad, Russ Housley)
Acknowlegements (Blake Ramsdell)
Changes since S/MIME v3 (Blake Ramsdell)
 End of changes. 

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