draft-ietf-smime-rfc2633bis-05.txt   draft-ietf-smime-rfc2633bis-06.txt 
Internet Draft Editor: Blake Ramsdell, Internet Draft Editor: Blake Ramsdell,
draft-ietf-smime-rfc2633bis-05.txt Brute Squad Labs draft-ietf-smime-rfc2633bis-06.txt Brute Squad Labs
June 30, 2003 October 26, 2003
Expires December 30, 2003 Expires April 26, 2004
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 140 skipping to change at line 140
objects, MIME body parts that contain CMS content types, or both. objects, MIME body parts that contain CMS content types, or both.
Sending agent: software that creates S/MIME CMS content types, MIME Sending agent: software that creates S/MIME CMS content types, MIME
body parts that contain CMS content types, 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.1 agents should attempt to have the greatest
interoperability possible with S/MIME version 2 agents. S/MIME version interoperability possible with agents for prior versions of S/MIME.
2 is described in RFC 2311 through RFC 2315, inclusive. RFC 2311 also S/MIME version 2 is described in RFC 2311 through RFC 2315, inclusive
has historical information about the development of S/MIME. and S/MIME version 3 is described in RFC 2630 through RFC 2634
inclusive. RFC 2311 also has historical information about the
development of S/MIME.
1.5 Changes Since S/MIME v3.0 1.5 Changes Since S/MIME v3.0
The RSA public key algorithm was changed to a MUST implement key The RSA public key algorithm was changed to a MUST implement key
wrapping algorithm, and the Diffie-Hellman algorithm changed to a wrapping algorithm, and the Diffie-Hellman algorithm changed to a
SHOULD implement. SHOULD implement.
The AES symmetric encryption algorithm has been included as a SHOULD The AES symmetric encryption algorithm has been included as a SHOULD
implement. implement.
skipping to change at line 206 skipping to change at line 208
backward compatibility with MD5-digested S/MIME v2 SignedData objects. backward compatibility with MD5-digested S/MIME v2 SignedData objects.
2.2 SignatureAlgorithmIdentifier 2.2 SignatureAlgorithmIdentifier
Receiving agents MUST support id-dsa-with-sha1 defined in [CMSALG]. Receiving agents MUST support id-dsa-with-sha1 defined in [CMSALG].
The algorithm parameters MUST be absent (not encoded as NULL). The algorithm parameters MUST be absent (not encoded as NULL).
Receiving agents MUST support rsaEncryption, defined in [CMSALG]. Receiving agents MUST support rsaEncryption, defined in [CMSALG].
Sending agents MUST support either id-dsa-with-sha1 or rsaEncryption. Sending agents MUST support either id-dsa-with-sha1 or rsaEncryption.
If using rsaEncryption, sending and receiving agents MUST support the
algorithms in section 2.1 as specified.
Note that S/MIME v3 clients might only implement signing or signature Note that S/MIME v3 clients might only implement signing or signature
verification using id-dsa-with-sha1, and might also use id-dsa as an verification using id-dsa-with-sha1, and might also use id-dsa as an
AlgorithmIdentifier in this field. Receiving clients SHOULD recognize AlgorithmIdentifier in this field. Receiving clients SHOULD recognize
id-dsa as equivalent to id-dsa-with-sha1, and sending clients MUST use id-dsa as equivalent to id-dsa-with-sha1, and sending clients MUST use
id-dsa-with-sha1 if using that algorithm. Also note that S/MIME v2 id-dsa-with-sha1 if using that algorithm. Also note that S/MIME v2
clients are only capable of verifying digital signatures using the clients are only required to verify digital signatures using the
rsaEncryption algorithm. rsaEncryption algorithm with SHA-1 or MD5, and may not implement
id-dsa-with-sha1 at all.
2.3 KeyEncryptionAlgorithmIdentifier 2.3 KeyEncryptionAlgorithmIdentifier
Sending and receiving agents MUST support rsaEncryption, defined in Sending and receiving agents MUST support rsaEncryption, defined in
[CMSALG]. [CMSALG].
Sending and receiving agents SHOULD support Diffie-Hellman defined in Sending and receiving agents SHOULD support Diffie-Hellman defined in
[CMSALG]. [CMSALG], using the ephemeral-static mode.
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, There are several CMS content types. Of these, only the Data,
SignedData, EnvelopedData and CompressedData content types are SignedData, EnvelopedData and CompressedData content types are
currently used for 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
skipping to change at line 267 skipping to change at line 273
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 2.4.4 CompressedData Content Type
This content type is used to apply data compression to a message. This This content type is used to apply data compression to a message. This
content type does not provide authentication or privacy, and is only content type does not provide authentication or privacy, and is only
used to reduce message size. used to reduce message size.
See section 3.6 for further guidance on the use of this type in
conjunction with other CMS types.
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:
skipping to change at line 288 skipping to change at line 297
- 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-messageDigest (section 11.2 in [CMS])
- id-contentType (section 11.1 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 signingCertificate signed attribute, as defined in instance in the signingCertificate signed attribute, as defined in
section 5 of [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 SignerInfo structure.
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.
Interactive sending agents that include signed attributes that are not Interactive sending agents that include signed attributes that are not
listed here SHOULD display those attributes to the user, so that the listed here SHOULD display those attributes to the user, so that the
user is aware 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
skipping to change at line 349 skipping to change at line 358
list doesn't get too long. In an SMIMECapabilities attribute, the list doesn't get too long. In an SMIMECapabilities attribute, the
object identifiers (OIDs) are listed in order of their preference, but object identifiers (OIDs) are listed in order of their preference, but
SHOULD be logically separated along the lines of their categories SHOULD be logically separated along the lines of their categories
(signature algorithms, symmetric algorithms, key encipherment (signature algorithms, symmetric algorithms, key encipherment
algorithms, etc.) 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. Because of the requirement for identical encoding,
individuals documenting algorithms to be used in the SMIMECapabilities
attribute should explicitly document the correct byte sequence for the
common cases.
In the case of symmetric algorithms, the associated parameters for the For any capability, the associated parameters for the OID MUST specify
OID MUST specify all of the parameters necessary to differentiate all of the parameters necessary to differentiate between two instances
between two instances of the same algorithm. For instance, the number of the same algorithm. For instance, the number of rounds and block
of rounds and block size for RC5 must be specified in addition to the size for RC5 must be specified in addition to the key length.
key length.
The OIDs used with S/MIME are assigned in several different RFCs. Note The OIDs used with S/MIME are assigned in several different RFCs. Note
that all OIDs associated with the MUST and SHOULD implement algorithms that all OIDs associated with the MUST and SHOULD implement algorithms
are included in section A of this document. 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
skipping to change at line 381 skipping to change at line 392
The registered SMIMECapabilities list specifies the parameters for The registered SMIMECapabilities list specifies the parameters for
OIDs that need them, most notably key lengths in the case of variable- OIDs that need them, most notably key lengths in the case of variable-
length symmetric ciphers. In the event that there are no length symmetric ciphers. In the event that there are no
differentiating parameters for a particular OID, the parameters MUST differentiating parameters for a particular OID, the parameters MUST
be omitted, and MUST NOT be encoded as NULL. be omitted, and MUST NOT be encoded as NULL.
Additional values for the SMIMECapabilities attribute may be defined Additional values for the SMIMECapabilities attribute may be defined
in the future. Receiving agents MUST handle a SMIMECapabilities object in the future. Receiving agents MUST handle a SMIMECapabilities object
that has values that it does not recognize in a graceful manner. that has values that it does not recognize in a graceful manner.
Section 2.7.1 explains a strategy for caching capabilities.
2.5.3 Encryption Key Preference Attribute 2.5.3 Encryption Key Preference Attribute
The encryption key preference attribute allows the signer to The encryption key preference attribute allows the signer to
unambiguously describe which of the signer's certificates has the unambiguously describe which of the signer's certificates has the
signer's preferred encryption key. This attribute is designed to signer's preferred encryption key. This attribute is designed to
enhance behavior for interoperating with those clients which use enhance behavior for interoperating with those clients which use
separate keys for encryption and signing. This attribute is used to separate keys for encryption and signing. This attribute is used to
convey to anyone viewing the attribute which of the listed convey to anyone viewing the attribute which of the listed
certificates should be used for encrypting a session key for future certificates should be used for encrypting a session key for future
encrypted messages. encrypted messages.
skipping to change at line 419 skipping to change at line 432
Receiving agents SHOULD store the preference data if the signature on Receiving agents SHOULD store the preference data if the signature on
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 skew currently stored value. (As with the SMIMECapabilities, the clock skew
should be checked and the data not used if the skew is too great.) should be checked and the data not used if the skew is too great.)
Receiving agents SHOULD respect the sender's encryption key preference Receiving agents SHOULD respect the sender's 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.
Section 2.7.1 explains a strategy for caching preference data.
2.5.3.1 Selection of Recipient Key Management Certificate 2.5.3.1 Selection of Recipient Key Management Certificate
In order to determine the key management certificate to be used when In order to determine the key management certificate to be used when
sending a future CMS envelopedData message for a particular recipient, sending a future CMS envelopedData message for a particular recipient,
the following steps SHOULD be followed: the following steps SHOULD be followed:
- If an SMIMEEncryptionKeyPreference attribute is found in a - If an SMIMEEncryptionKeyPreference attribute is found in a
signedData object received from the desired recipient, this signedData object received from the desired recipient, this
identifies the X.509 certificate that should be used as the X.509 identifies the X.509 certificate that should be used as the X.509
key management certificate for the recipient. key management certificate for the recipient.
skipping to change at line 448 skipping to change at line 463
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.1 and S/MIME v3 requires the use of SignerInfo version 1, S/MIME v3.1 and S/MIME v3 requires the use of SignerInfo version 1,
that is the issuerAndSerialNumber CHOICE MUST be used for that is the issuerAndSerialNumber CHOICE MUST be used for
SignerIdentifier. SignerIdentifier.
S/MIME v3.1 implementations MUST allow for the use of the choice of
subjectKeyIdentifier in messages. Messages that use this choice cannot
be read by S/MIME v2 clients, and MUST be handled gracefully in S/MIME
v3.1 clients.
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". Sending and receiving agents SHOULD support encryption and "RC2/40". Sending and receiving agents SHOULD support encryption and
decryption with AES [CMSAES] at a key size of 128, 192 and 256 bits. decryption with AES [CMSAES] at a key size of 128, 192 and 256 bits.
2.7.1 Deciding Which Encryption Method To Use 2.7.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.
Section 2.5 defines a method by which a sending agent can optionally Section 2.5.2 defines a method by which a sending agent can optionally
announce, among other things, its decrypting capabilities in its order announce, among other things, its decrypting capabilities in its order
of preference. The following method for processing and remembering the of preference. The following method for processing and remembering the
encryption capabilities attribute in incoming signed messages SHOULD encryption capabilities attribute in incoming signed messages SHOULD
be used. be used.
- If the receiving agent has not yet created a list of capabilities - If the receiving agent has not yet created a list of capabilities
for the sender's public key, then, after verifying the signature on for the sender's public key, then, after verifying the signature on
the incoming message and checking the timestamp, the receiving agent the incoming message and checking the timestamp, the receiving agent
SHOULD create a new list containing at least the signing time and SHOULD create a new list containing at least the signing time and
the symmetric capabilities. the symmetric capabilities.
skipping to change at line 514 skipping to change at line 534
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.7.1.2 Rule 2: Unknown Capabilities, Known Use of Encryption 2.7.1.2 Rule 2: Unknown Capabilities, Unknown Version of S/MIME
If the following three conditions are met:
- the sending agent has no knowledge of the encryption capabilities
of the recipient,
- and the sending agent has received at least one message from the
recipient,
- and the last encrypted message received from the recipient had a
trusted signature on it,
then the outgoing message SHOULD use the same encryption algorithm as
was used on the last signed and encrypted message received from the
recipient.
2.7.1.3 Rule 3: Unknown Capabilities, Unknown Version of S/MIME
If the following two conditions are met: 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.
skipping to change at line 637 skipping to change at line 644
entity is typically passed to a MIME-capable user agent where, it is entity is typically passed to a MIME-capable user agent where, it is
further decoded and presented to the user or receiving application. further decoded and presented to the user or receiving application.
In order to protect outer, non-content related message headers (for In order to protect outer, non-content related message headers (for
instance, the "Subject", "To", "From" and "CC" fields), the sending instance, the "Subject", "To", "From" and "CC" fields), the sending
client MAY wrap a full MIME message in a message/rfc822 wrapper in client MAY wrap a full MIME message in a message/rfc822 wrapper in
order to apply S/MIME security services to these headers. It is up to order to apply S/MIME security services to these headers. It is up to
the receiving client to decide how to present these "inner" headers the receiving client to decide how to present these "inner" headers
along with the unprotected "outer" headers. along with the unprotected "outer" headers.
When an S/MIME message is received, if the top-level protected MIME
entity has a Content-Type of message/rfc822, it can be assumed that
the intent was to provide header protection. This entity should be
presented as the top-level message, taking into account header merging
issues as previously discussed.
3.1.1 Canonicalization 3.1.1 Canonicalization
Each MIME entity MUST be converted to a canonical form that is Each MIME entity MUST be converted to a canonical form that is
uniquely and unambiguously representable in the environment where the uniquely and unambiguously representable in the environment where the
signature is created and the environment where the signature will be signature is created and the environment where the signature will be
verified. MIME entities MUST be canonicalized for enveloping as well verified. MIME entities MUST be canonicalized for enveloping and
as signing. compressing as well as signing.
The exact details of canonicalization depend on the actual MIME type The exact details of canonicalization depend on the actual MIME type
and subtype of an entity, and are not described here. Instead, the and subtype of an entity, and are not described here. Instead, the
standard for the particular MIME type should be consulted. For standard for the particular MIME type should be consulted. For
example, canonicalization of type text/plain is different from example, canonicalization of type text/plain is different from
canonicalization of audio/basic. Other than text types, most types canonicalization of audio/basic. Other than text types, most types
have only one representation regardless of computing platform or have only one representation regardless of computing platform or
environment which can be considered their canonical representation. In environment which can be considered their canonical representation. In
general, canonicalization will be performed by the non-security part general, canonicalization will be performed by the non-security part
of the sending agent rather than the S/MIME implementation. of the sending agent rather than the S/MIME implementation.
skipping to change at line 690 skipping to change at line 703
handled in any environment without changing it. For example, a trusted handled in any environment without changing it. For example, a trusted
gateway might remove the envelope, but not the signature, of a gateway might remove the envelope, but not the signature, of a
message, and then forward the signed message on to the end recipient message, and then forward the signed message on to the end recipient
so that they can verify the signatures directly. If the transport so that they can verify the signatures directly. If the transport
internal to the site is not 8-bit clean, such as on a wide-area internal to the site is not 8-bit clean, such as on a wide-area
network with a single mail gateway, verifying the signature will not network with a single mail gateway, verifying the signature will not
be possible unless the original MIME entity was only 7-bit data. be possible unless the original MIME entity was only 7-bit data.
S/MIME implementations which "know" that all intended recipient(s) are S/MIME implementations which "know" that all intended recipient(s) are
capable of handling inner (all but the outermost) binary MIME objects capable of handling inner (all but the outermost) binary MIME objects
SHOULD NOT use 7-bit transfer encoding for the inner entities since SHOULD use binary encoding as opposed to a 7-bit-safe transfer
this would unnecessarily expand the message size. Implementations MAY encoding for the inner entities. The use of a 7-bit-safe encoding
"know" that recipient implementations are capable of handling inner (such as base64) would unnecessarily expand the message size.
binary MIME entities either by interpreting the Implementations MAY "know" that recipient implementations are capable
of handling inner binary MIME entities either by interpreting the
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
skipping to change at line 851 skipping to change at line 865
attachment off to, in this case a stand-alone S/MIME processing attachment off to, in this case a stand-alone S/MIME processing
application. Note that this mechanism is provided as a convenience for application. Note that this mechanism is provided as a convenience for
implementations in certain environments. A proper S/MIME implementations in certain environments. A proper S/MIME
implementation MUST use the MIME types and MUST NOT rely on the file implementation MUST use the MIME types and MUST NOT rely on the file
extensions. extensions.
3.2.2 The smime-type parameter 3.2.2 The smime-type parameter
The application/pkcs7-mime content type defines the optional "smime- The application/pkcs7-mime content type defines the optional "smime-
type" parameter. The intent of this parameter is to convey details type" parameter. The intent of this parameter is to convey details
about the security applied (signed or enveloped) along with infomation about the security applied (signed or enveloped) along with
about the contained content. This specification defines the following information about the contained content. This specification defines
smime-types. the following smime-types.
Name CMS type Inner Content Name CMS type Inner Content
enveloped-data EnvelopedData id-data enveloped-data EnvelopedData id-data
signed-data SignedData id-data signed-data SignedData id-data
certs-only SignedData none certs-only SignedData none
compressed-data CompressedData id-data compressed-data CompressedData id-data
skipping to change at line 944 skipping to change at line 958
Messages signed using the multipart/signed format can always be viewed Messages signed using the multipart/signed format can always be viewed
by the receiver whether they have S/MIME software or not. They can by the receiver whether they have S/MIME software or not. They can
also be viewed whether they are using a MIME-native user agent or they also be viewed whether they are using a MIME-native user agent or they
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, the signedData
S/MIME facilities, these messages can always be verified if they were format protects the message content from being changed by benign
not changed in transit. intermediate agents. Such agents might do line wrapping or
content-transfer encoding changes which would break the signature.
3.4.2 Signing Using application/pkcs7-mime with 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
skipping to change at line 1043 skipping to change at line 1058
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-256 sha256
SHA-384 sha384 SHA-384 sha384
SHA-512 sha512 SHA-512 sha512
Any other unknown Any other (defined separately in algorithm profile or "unknown"
if not defined)
(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 The SHA-256, SHA-384 and SHA-512 algorithms [FIPS180-2] are not
currently supported in S/MIME, and are included here for completeness. 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
skipping to change at line 1076 skipping to change at line 1092
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--
The content that is digested (the first part of the multipart/signed)
are the bytes:
43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 70 6c 61 69
6e 0d 0a 0d 0a 54 68 69 73 20 69 73 20 61 20 63 6c 65 61 72 2d 73 69
67 6e 65 64 20 6d 65 73 73 61 67 65 2e 0d 0a
3.5 Creating an Compressed-only Message 3.5 Creating an Compressed-only Message
This section describes the format for compressing a MIME entity. This section describes the format for compressing a MIME entity.
Please note that versions of S/MIME prior to 3.1 did not specify any Please note that versions of S/MIME prior to 3.1 did not specify any
use of compressedData, and will not recognize it. The use of a use of compressedData, and will not recognize it. The use of a
capability to indicate the ability to receive compressedData is capability to indicate the ability to receive compressedData is
described in [CMSCOMPR] and is the preferred method for compatibility. described in [CMSCOMPR] and is the preferred method for compatibility.
Step 1. The MIME entity to be enveloped is prepared according to Step 1. The MIME entity to be enveloped is prepared according to
section 3.1. section 3.1.
skipping to change at line 1213 skipping to change at line 1236
MIME type: application/octet-stream MIME type: application/octet-stream
parameters: any parameters: any
file suffix: p7m, p7s, p7c, p7z file suffix: p7m, p7s, p7c, p7z
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 specification does not cover how S/MIME agents handle envelopes. This specification 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 [CERT3]. or rejected. S/MIME certification issues are covered in [CERT31].
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
If an S/MIME agent needs to generate a key pair, then the S/MIME agent All generated key pairs MUST be generated from a good source of non-
or some related administrative utility or function MUST be capable 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-
deterministic random input [RANDOM] and the private key MUST be deterministic random input [RANDOM] and the private key MUST be
protected in a secure fashion. protected in a 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 an RSA key pair, then the S/MIME
or some related administrative utility or function SHOULD generate RSA agent or some related administrative utility or function SHOULD
key pairs. generate RSA key pairs using the following guidelines. A user agent
SHOULD generate RSA key pairs at a minimum key size of 768 bits. A
A user agent SHOULD generate RSA key pairs at a minimum key size of user agent MUST NOT generate RSA key pairs less than 512 bits long.
768 bits. A user agent MUST NOT generate RSA key pairs less than 512 Creating keys longer than 1024 bits may cause some older S/MIME
bits long. Creating keys longer than 1024 bits may cause some older receiving agents to not be able to verify signatures, but gives better
S/MIME receiving agents to not be able to verify signatures, but gives security and is therefore valuable. A receiving agent SHOULD be able
better security and is therefore valuable. A receiving agent SHOULD be to verify signatures with keys of any size over 512 bits. Some agents
able to verify signatures with keys of any size over 512 bits. Some created in the United States have chosen to create 512 bit keys in
agents created in the United States have chosen to create 512 bit keys order to get more advantageous export licenses. However, 512 bit keys
in order to get more advantageous export licenses. However, 512 bit are considered by many to be cryptographically insecure. Implementors
keys are considered by many to be cryptographically insecure. should be aware that multiple (active) key pairs may be associated
Implementors should be aware that multiple (active) key pairs may be with a single individual. For example, one key pair may be used to
associated with a single individual. For example, one key pair may be support confidentiality, while a different key pair may be used for
used to support confidentiality, while a different key pair may be authentication.
used for authentication.
5. Security 5. Security
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
cryptographic capabilities to parties with whom you communicate, allow cryptographic capabilities to parties with whom you communicate, allow
senders to create messages that use strong encryption. Using weak senders to create messages that use strong encryption. Using weak
cryptography is never recommended unless the only alternative is no cryptography is never recommended unless the only alternative is no
skipping to change at line 1453 skipping to change at line 1472
Paul Hoffman Paul Hoffman
Russ Housley Russ Housley
William Ottaway William Ottaway
John Pawling John Pawling
Jim Schaad Jim Schaad
D. Editor's address D. Editor's address
Blake Ramsdell Blake Ramsdell
Brute Squad Labs Brute Squad Labs
Suite 217-C Suite 407-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
id-dsa change to id-dsa-with-sha1 (Blake Ramsdell) Numerous changes (Jim Schaad)
Added AES as a SHOULD (Paul Hoffman)
 End of changes. 

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