draft-ietf-smime-rfc2633bis-00.txt   draft-ietf-smime-rfc2633bis-01.txt 
Internet Draft Editor: Blake Ramsdell, Internet Draft Editor: Blake Ramsdell,
draft-ietf-smime-rfc2633bis-00.txt Brute Squad Labs draft-ietf-smime-rfc2633bis-01.txt Brute Squad Labs
February 8, 2002 June 30, 2002
Expires August 8, 2002 Expires December 30, 2002
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 35 skipping to change at line 35
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
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 data confidentiality (using encryption).
S/MIME can be used by traditional mail user agents (MUAs) to add S/MIME can be used by traditional mail user agents (MUAs) to add
cryptographic security services to mail that is sent, and to interpret cryptographic security services to mail that is sent, and to interpret
cryptographic security services in mail that is received. However, cryptographic security services in mail that is received. However,
S/MIME is not restricted to mail; it can be used with any transport S/MIME is not restricted to mail; it can be used with any transport
mechanism that transports MIME data, such as HTTP. As such, S/MIME mechanism that transports MIME data, such as HTTP. As such, S/MIME
takes advantage of the object-based features of MIME and allows secure takes advantage of the object-based features of MIME and allows secure
messages to be exchanged in mixed-transport systems. messages to be exchanged in mixed-transport systems.
Further, S/MIME can be used in automated message transfer agents that Further, S/MIME can be used in automated message transfer agents that
skipping to change at line 57 skipping to change at line 57
intervention, such as the signing of software-generated documents and intervention, such as the signing of software-generated documents and
the encryption of FAX messages sent over the Internet. the encryption of FAX messages sent over the Internet.
1.1 Specification Overview 1.1 Specification Overview
This document describes a protocol for adding cryptographic signature This document describes a protocol for adding cryptographic signature
and encryption services to MIME data. The MIME standard [MIME-SPEC] and encryption services to MIME data. The MIME standard [MIME-SPEC]
provides a general structure for the content type of Internet messages provides a general structure for the content type of Internet messages
and allows extensions for new content type applications. and allows extensions for new content type applications.
This draft defines how to create a MIME body part that has been This specification defines how to create a MIME body part that has
cryptographically enhanced according to CMS [CMS], which is derived been cryptographically enhanced according to CMS [CMS], which is
from PKCS #7 [PKCS-7]. This draft also defines the application/pkcs7- derived from PKCS #7 [PKCS-7]. This specification also defines the
mime MIME type that can be used to transport those body parts. application/pkcs7- mime MIME type that can be used to transport those
body parts.
This draft also discusses how to use the multipart/signed MIME type This specification also discusses how to use the multipart/signed MIME
defined in [MIME-SECURE] to transport S/MIME signed messages. This type defined in [MIME-SECURE] to transport S/MIME signed messages.
draft also defines the application/pkcs7-signature MIME type, which is multipart/signed is used in conjunction with the
also used to transport S/MIME signed messages. application/pkcs7-signature MIME type, which is used to transport
a detached S/MIME signature.
In order to create S/MIME messages, an S/MIME agent has to follow In order to create S/MIME messages, an S/MIME agent has to follow the
specifications in this draft, as well as the specifications listed in specifications in this document, as well as the specifications
the Cryptographic Message Syntax [CMS]. listed in the Cryptographic Message Syntax [CMS].
Throughout this draft, there are requirements and recommendations made Throughout this specification, there are requirements and
for how receiving agents handle incoming messages. There are separate recommendations made for how receiving agents handle incoming
requirements and recommendations for how sending agents create messages. There are separate requirements and recommendations for how
outgoing messages. In general, the best strategy is to "be liberal in sending agents create outgoing messages. In general, the best strategy
what you receive and conservative in what you send". Most of the is to "be liberal in what you receive and conservative in what you
requirements are placed on the handling of incoming messages while the send". Most of the requirements are placed on the handling of incoming
recommendations are mostly on the creation of outgoing messages. messages while the recommendations are mostly on the creation of
outgoing messages.
The separation for requirements on receiving agents and sending agents The separation for requirements on receiving agents and sending agents
also derives from the likelihood that there will be S/MIME systems also derives from the likelihood that there will be S/MIME systems
that involve software other than traditional Internet mail clients. that involve software other than traditional Internet mail clients.
S/MIME can be used with any system that transports MIME data. An S/MIME can be used with any system that transports MIME data. An
automated process that sends an encrypted message might not be able to automated process that sends an encrypted message might not be able to
receive an encrypted message at all, for example. Thus, the receive an encrypted message at all, for example. Thus, the
requirements and recommendations for the two types of agents are requirements and recommendations for the two types of agents are
listed separately when appropriate. listed separately when appropriate.
1.2 Terminology 1.2 Terminology
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 draft, the following definitions apply. For the purposes of this specification, the following definitions
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.
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.
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.
skipping to change at line 139 skipping to change at line 143
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.
1.5 Discussion of This Draft 1.5 Changes Since S/MIME v3.0
This draft is being discussed on the "ietf-smime" mailing list. To [TBD]
subscribe, send a message to:
1.6 Discussion of This Specification
This specification is being discussed on the "ietf-smime" mailing
list. To subscribe, send a message to:
ietf-smime-request@imc.org ietf-smime-request@imc.org
with the single word with the single word
subscribe subscribe
in the body of the message. There is a Web site for the mailing list in the body of the message. There is a Web site for the mailing list
at <http://www.imc.org/ietf-smime/>. at <http://www.imc.org/ietf-smime/>.
skipping to change at line 190 skipping to change at line 198
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].
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, 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 id-data content type identifier to Sending agents MUST use the id-data content type identifier to
indicate the message content which has had security services applied identify the "inner" MIME message content. For example, when applying
to it. For example, when applying a digital signature to MIME data, a digital signature to MIME data, the CMS signedData encapContentInfo
the CMS signedData encapContentInfo eContentType MUST include the id- eContentType MUST include the id-data object identifier and the MIME
data object identifier and the MIME content MUST be stored in the content MUST be stored in the SignedData encapContentInfo eContent
SignedData encapContentInfo eContent OCTET STRING (unless the sending OCTET STRING (unless the sending agent is using multipart/signed, in
agent is using multipart/signed, in which case the eContent is absent, which case the eContent is absent, per section 3.4.3 of this
per section 3.4.3 of this document). As another example, when applying document). As another example, when applying encryption to MIME data,
encryption to MIME data, the CMS EnvelopedData encryptedContentInfo the CMS EnvelopedData encryptedContentInfo ContentType MUST include
ContentType MUST include the id-data object identifier and the the id-data object identifier and the encrypted MIME content MUST be
encrypted MIME content MUST be stored in the envelopedData stored in the envelopedData encryptedContentInfo encryptedContent
encryptedContentInfo encryptedContent OCTET STRING. 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 data confidentiality to a message.
sender needs to have access to a public key for each intended message A sender needs to have access to a public key for each intended
recipient to use this service. This content type does not provide message recipient to use this service. This content type does not
authentication. provide authentication.
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: - signingTime (section 2.5.1 in this document) - message:
sMIMECapabilities (section 2.5.2 in this document) -
sMIMEEncryptionKeyPreference (section 2.5.3 in this document) - signingTime (section 2.5.1 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)
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 signed attributes of the signingCertificate attribute
(section 5 in [ESS]). (section 5 in [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 Sending agents that include signed attributes that are not listed here
SHOULD display those attributes to the user, so that the user is aware SHOULD display those attributes to the user, so that the user is aware
of all of the data being signed. 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. Until there are trusted timestamping services, the time of was signed. The time of signing will most likely be created by a
signing will most likely be created by a message originator and message originator and therefore is only as trustworthy as the
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
GeneralizedTime. When the UTCTime CHOICE is used, S/MIME agents MUST GeneralizedTime. When the UTCTime CHOICE is used, S/MIME agents MUST
interpret the year field (YY) as follows: 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
skipping to change at line 312 skipping to change at line 322
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 There is a list of OIDs (OIDs Used with S/MIME) that is centrally
maintained and is separate from this draft. The list of OIDs is maintained and is separate from this specification. The list of OIDs
maintained by the Internet Mail Consortium at is maintained by the Internet Mail Consortium at
<http://www.imc.org/ietf- smime/oids.html>. Note that all OIDs <http://www.imc.org/ietf- smime/oids.html>. Note that all OIDs
associated with the MUST and SHOULD implement algorithms are included associated with the MUST and SHOULD implement algorithms are included
in section A of this document. 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 draft, 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.
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
skipping to change at line 428 skipping to change at line 438
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 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 for the sender's public key, then, after verifying the signature on
on the incoming message and checking the timestamp, the receiving the incoming message and checking the timestamp, the receiving agent
agent SHOULD create a new list containing at least the signing SHOULD create a new list containing at least the signing time and
time and the symmetric capabilities. 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
the signing time stored in the list and that the signature is signing time stored in the list and that the signature is valid. If
valid. If so, the receiving agent SHOULD update both the signing so, the receiving agent SHOULD update both the signing time and
time and capabilities in the list. Values of the signing time that capabilities in the list. Values of the signing time that lie far in
lie far in the future (that is, a greater discrepancy than any the future (that is, a greater discrepancy than any reasonable clock
reasonable clock skew), or a capabilities list in messages whose skew), or a capabilities list in messages whose signature could not
signature could not be verified, MUST NOT be accepted. 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
skipping to change at line 583 skipping to change at line 593
form form
Step 3. Appropriate transfer encoding is applied to the leaves of the Step 3. Appropriate transfer encoding is applied to the leaves of the
MIME entity MIME entity
When an S/MIME message is received, the security services on the When an S/MIME message is received, the security services on the
message are processed, and the result is the MIME entity. That MIME message are processed, and the result is the MIME entity. That MIME
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.
[TBD] 2822 header protection
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 as well
as signing. 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
skipping to change at line 751 skipping to change at line 763
with older systems. Sending agents SHOULD also emit the optional with older systems. Sending agents SHOULD also emit the optional
Content-Disposition field [CONTDISP] with the "filename" parameter. If Content-Disposition field [CONTDISP] with the "filename" parameter. If
a sending agent emits the above parameters, the value of the a sending agent emits the above parameters, the value of the
parameters SHOULD be a file name with the appropriate extension: parameters SHOULD be a file name with the appropriate extension:
MIME Type File Extension MIME Type File Extension
Application/pkcs7-mime (signedData, envelopedData) .p7m Application/pkcs7-mime (signedData, envelopedData) .p7m
Application/pkcs7-mime (degenerate signedData .p7c Application/pkcs7-mime (degenerate signedData .p7c
"certs-only" message) certificate management message)
Application/pkcs7-signature .p7s Application/pkcs7-signature .p7s
In addition, the file name SHOULD be limited to eight characters In addition, the file name SHOULD be limited to eight characters
followed by a three letter extension. The eight character filename followed by a three letter extension. The eight character filename
base can be any distinct name; the use of the filename base "smime" base can be any distinct name; the use of the filename base "smime"
SHOULD be used to indicate that the MIME entity is associated with SHOULD be used to indicate that the MIME entity is associated with
S/MIME. S/MIME.
Including a file name serves two purposes. It facilitates easier use Including a file name serves two purposes. It facilitates easier use
skipping to change at line 781 skipping to change at line 793
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 infomation
about the contained content. This draft defines the following smime- about the contained content. This specification defines the following
types. smime- types.
Name Security Inner Content Name Security 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 cert-management SignedData none
In order that consistency can be obtained with future, the following In order that consistency can be obtained with future, the following
guidelines should be followed when assigning a new smime-type guidelines should be followed when assigning a new smime-type
parameter. parameter.
1. If both signing and encryption can be applied to the content, then 1. If both signing and encryption can be applied to the content, then
two values for smime-type SHOULD be assigned "signed-*" and two values for smime-type SHOULD be assigned "signed-*" and
"encrypted- *". If one operation can be assigned then this may be "encrypted- *". If one operation can be assigned then this may be
omitted. Thus since "certs-only" can only be signed, "signed-" is omitted. Thus since "cert-management" can only be signed, "signed-" is
omitted. omitted.
2. A common string for a content oid should be assigned. We use "data" 2. A common string for a content oid should be assigned. We use "data"
for the id-data content OID when MIME is the inner content. for the id-data content OID when MIME is the inner content.
3. If no common string is assigned. Then the common string of 3. If no common string is assigned. Then the common string of
"OID.<oid>" is recommended (for example, "OID.1.3.6.1.5.5.7.6.1" would "OID.<oid>" is recommended (for example, "OID.1.3.6.1.5.5.7.6.1" would
be DES40). be DES40).
3.3 Creating an Enveloped-only Message 3.3 Creating an Enveloped-only Message
skipping to change at line 822 skipping to change at line 834
signing it. It is important to note that sending enveloped but not signing it. It is important to note that sending enveloped but not
signed messages does not provide for data integrity. It is possible to signed messages does not provide for data integrity. It is possible to
replace ciphertext in such a way that the processed message will still replace ciphertext in such a way that the processed message will still
be valid, but the meaning may be altered. be valid, but the meaning may be altered.
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.
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 envelopedData. In addition to encrypting a copy of CMS object of type envelopedData. In addition to encrypting a copy of
the content-encryption key for each recipient, a copy of the content the content-encryption key for each recipient, a copy of the content-
encryption key SHOULD be encrypted for the originator and included in encryption key SHOULD be encrypted for the originator and included in
the envelopedData (see CMS Section 6). the envelopedData (see CMS Section 6).
Step 3. The CMS object is inserted into an application/pkcs7-mime MIME Step 3. The envelopedData object is wrapped in a CMS ContentInfo
entity. object.
Step 4. The ContentInfo object is inserted into an
application/pkcs7-mime MIME entity.
The smime-type parameter for enveloped-only messages is "enveloped- The smime-type parameter for enveloped-only messages is "enveloped-
data". The file extension for this type of message is ".p7m". data". The file extension for this type of message is ".p7m".
A sample message would be: A sample message would be:
Content-Type: application/pkcs7-mime; smime-type=enveloped-data; Content-Type: application/pkcs7-mime; smime-type=enveloped-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
skipping to change at line 882 skipping to change at line 897
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
Step 3. The CMS object is inserted into an application/pkcs7-mime MIME Step 3. The signedData object is wrapped in a CMS ContentInfo
entity object.
Step 4. The ContentInfo object is inserted into an
application/pkcs7-mime MIME entity.
The smime-type parameter for messages using application/pkcs7-mime The smime-type parameter for messages using application/pkcs7-mime
with 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
skipping to change at line 913 skipping to change at line 931
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 CMS 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 signed; the second part contains the "detached MIME entity that is signed; the second part contains the "detached
signature" CMS SignedData object in which the encapContentInfo signature" CMS SignedData object in which the encapContentInfo
eContent field is absent. 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 CMS ContentInfo containing a single
The signedData encapContentInfo eContent field MUST be absent. The CMS object of type signedData. The signedData encapContentInfo
signerInfos field contains the signatures for the MIME entity. eContent field MUST be absent. The signerInfos field contains the
signatures for the MIME entity.
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
skipping to change at line 993 skipping to change at line 1012
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756 7GhIGfHfYT64VQbnj756
--boundary42-- --boundary42--
3.5 Signing and Encrypting 3.5 Signing and Encrypting
To achieve signing and enveloping, any of the signed-only and To achieve signing and enveloping, any of the signed-only and
encrypted-only formats may be nested. This is allowed because the encrypted-only MIME formats listed above may be nested. This is
above formats are all MIME entities, and because they all secure MIME allowed because the above formats are all MIME entities, and because
entities. they all secure MIME 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 either sign a message first, or to envelope the It is possible to either sign a message first, or to envelope the
message first. It is up to the implementor and the user to choose. message first. It is up to the implementor and the user to choose.
When signing first, the signatories are then securely obscured by the When signing first, the signatories are then securely obscured by the
enveloping. When enveloping first the signatories are exposed, but it enveloping. When enveloping first the signatories are exposed, but it
is possible to verify signatures without removing the enveloping. This is possible to verify signatures without removing the enveloping. This
skipping to change at line 1019 skipping to change at line 1038
There are security ramifications to choosing whether to sign first or There are security ramifications to choosing whether to sign first or
encrypt first. A recipient of a message that is encrypted and then encrypt first. A recipient of a message that is encrypted and then
signed can validate that the encrypted block was unaltered, but cannot signed can validate that the encrypted block was unaltered, but cannot
determine any relationship between the signer and the unencrypted determine any relationship between the signer and the unencrypted
contents of the message. A recipient of a message that is signed-then- contents of the message. A recipient of a message that is signed-then-
encrypted can assume that the signed message itself has not been encrypted can assume that the signed message itself has not been
altered, but that a careful attacker may have changed the altered, but that a careful attacker may have changed the
unauthenticated portions of the encrypted message. unauthenticated portions of the encrypted message.
3.6 Creating a Certificates-only Message 3.6 Creating a Certificate Management Message
The certificates only message or MIME entity is used to transport The certificate management message or MIME entity is used to transport
certificates, such as in response to a registration request. This certificates and/or certificate revocation lists, such as in response
format can also be used to convey CRLs. to a registration request.
Step 1. The certificates are made available to the CMS generating Step 1. The certificates and/or certificate revocation lists are made
process which creates a CMS object of type signedData. The signedData available to the CMS generating process which creates a CMS object of
encapContentInfo eContent field MUST be absent and signerInfos field type signedData. The signedData encapContentInfo eContent field MUST
MUST be empty. be absent and signerInfos field MUST be empty.
Step 2. The CMS signedData object is enclosed in an application/pkcs7- Step 2. The signedData object is wrapped in a CMS ContentInfo
object.
Step 3. The ContentInfo 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 The smime-type parameter for a certificate management message is
file extension for this type of message is ".p7c". "cert-management". The file extension for this type of message is
".p7c".
Please note that in prior versions of S/MIME, the smime-type parameter
was set to "certs-only" for messages that contained only certificates
and/or certificate revocation lists. The new use of "cert-management"
is meant to clarify the semantic that both certificates and
certificate revocation lists might be found in these messages.
Receiving implementations SHOULD accept "certs-only" and
"cert-management" and treat them equivalently (that is, both could
contain certificates and/or certificate revocation lists).
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
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 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 specification. S/MIME v3 does not specify how to request
certificate, but instead mandates that every sending agent already has a certificate, but instead mandates that every sending agent already
a certificate. Standardization of certificate management is being has a certificate. Standardization of certificate management is being
pursued separately in the IETF. pursued separately in the IETF.
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 1083 skipping to change at line 1115
file suffix: any file suffix: any
MIME type: application/octet-stream MIME type: application/octet-stream
parameters: any parameters: any
file suffix: p7m, p7s, p7c file suffix: p7m, p7s, 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 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 [CERT3].
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.
skipping to change at line 1123 skipping to change at line 1155
agents created in the United States have chosen to create 512 bit keys agents created in the United States have chosen to create 512 bit keys
in order to get more advantageous export licenses. However, 512 bit in order to get more advantageous export licenses. However, 512 bit
keys are considered by many to be cryptographically insecure. keys are considered by many to be cryptographically insecure.
Implementors should be aware that multiple (active) key pairs may be Implementors should be aware that multiple (active) key pairs may be
associated with a single individual. For example, one key pair 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 to support confidentiality, while a different key pair may be
used for authentication. used for authentication.
5. Security 5. Security
This entire draft discusses security. Security issues not covered in
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
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
cryptography. When feasible, sending and receiving agents should cryptography. When feasible, sending and receiving agents should
inform senders and recipients the relative cryptographic strength of inform senders and recipients the relative cryptographic strength of
messages. messages.
It is impossible for most software or people to estimate the value of It is impossible for most software or people to estimate the value of
a message. Further, it is impossible for most software or people to a message. Further, it is impossible for most software or people to
estimate the actual cost of decrypting a message that is encrypted estimate the actual cost of decrypting a message that is encrypted
with a key of a particular size. Further, it is quite difficult to with a key of a particular size. Further, it is quite difficult to
determine the cost of a failed decryption if a recipient cannot decode determine the cost of a failed decryption if a recipient cannot decode
a message. Thus, choosing between different key sizes (or choosing a message. Thus, choosing between different key sizes (or choosing
whether to just use plaintext) is also impossible. However, decisions whether to just use plaintext) is also impossible. However, decisions
based on these criteria are made all the time, and therefore this based on these criteria are made all the time, and therefore this
draft gives a framework for using those estimates in choosing specification gives a framework for using those estimates in choosing
algorithms. algorithms.
If a sending agent is sending the same message using different If a sending agent is sending the same message using different
strengths of cryptography, an attacker watching the communications strengths of cryptography, an attacker watching the communications
channel may be able to determine the contents of the strongly- channel may be able to determine the contents of the strongly-
encrypted message by decrypting the weakly-encrypted version. In other encrypted message by decrypting the weakly-encrypted version. In other
words, a sender should not send a copy of a message using weaker words, a sender should not send a copy of a message using weaker
cryptography than they would use for the original of the message. cryptography than they would use for the original of the message.
Modification of the ciphertext can go undetected if authentication is Modification of the ciphertext can go undetected if authentication is
not also used, which is the case when sending EnvelopedData without not also used, which is the case when sending EnvelopedData without
wrapping it in SignedData or enclosing SignedData within it. wrapping it in SignedData or enclosing SignedData within it.
[TBD] -- PKCS #1 v1.5 warnings? [TBD] -- PKCS #1 v1.5 warnings (RFC 3218)
[TBD] -- Small subgroup Diffie-Hellman (RFC 2785)
A. ASN.1 Module A. ASN.1 Module
SecureMimeMessageV3 SecureMimeMessageV3
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) smime(4) } pkcs(1) pkcs-9(9) smime(16) modules(0) smime(4) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
skipping to change at line 1208 skipping to change at line 1239
-- prefered encryption certificate. -- prefered encryption certificate.
id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11} id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11}
SMIMEEncryptionKeyPreference ::= CHOICE { SMIMEEncryptionKeyPreference ::= CHOICE {
issuerAndSerialNumber [0] IssuerAndSerialNumber, issuerAndSerialNumber [0] IssuerAndSerialNumber,
receipentKeyId [1] RecipientKeyIdentifier, receipentKeyId [1] RecipientKeyIdentifier,
subjectAltKeyIdentifier [2] SubjectKeyIdentifier subjectAltKeyIdentifier [2] SubjectKeyIdentifier
} }
dES-EDE3-CBC OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549)
encryptionAlgorithm(3) 7}
CBCParameter ::= IV
IV ::= OCTET STRING (SIZE (8..8))
rC2-CBC OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549)
encryptionAlgorithm(3) 2}
RC2-CBC-parameter ::= SEQUENCE {
rc2ParameterVersion INTEGER,
iv IV}
-- The following list the OIDs to be used with S/MIME V3 -- The following list the OIDs to be used with S/MIME V3
-- Signature Algorithms Not Found in [CMSALG]
== digestAlgorithm(2) 5}
-- --
-- md2WithRSAEncryption OBJECT IDENTIFIER ::= -- md2WithRSAEncryption OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) -- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
-- 2} -- 2}
-- --
-- Other Signed Attributes -- Other Signed Attributes
-- --
-- signingTime OBJECT IDENTIFIER ::= -- signingTime OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) -- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
-- 5} -- 5}
-- See [CMS] for a description of how to encode the attribute -- See [CMS] for a description of how to encode the attribute
-- value. -- value.
END END
skipping to change at line 1331 skipping to change at line 1299
[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
C. Acknowledgements C. Acknowledgements
[tbd] [tbd]
D. Changes from last draft D. Editor's address
Edited as plain text due to unfortunate loss of original Word
document, so wrapping may change randomly, but strange 8bit characters
should no longer appear mysteriously (Blake Ramsdell)
2.3 changed Diffie-Hellman MAY to SHOULD per London IETF
E. Editor's address
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
Changed draft to specification in lots of places (Russ Housley)
Privacy changed to data confidentiality (Russ Housley)
Added section 1.5 for changes since S/MIME v3.0 (Russ Housley)
Blown bulleted list in section 2.5 (Russ Housley, Jim Schaad)
Yanked reference to timestamping service in section 2.5.1 (Russ
Housley)
Yanked OIDs found in [CMSALG] (Russ Housley)
Attempt at better English for first sentence of section 2.4.1 (Jim
Schaad)
Crazy English in section 1.1 3rd paragraph is probably worse (Piers
Chivers)
Various other language clarifications (Piers Chivers)
Hammered on section 3.6 for "certificate management" vs. "certs-only"
(William Ottaway)
 End of changes. 

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