draft-ietf-smime-rfc2633bis-07.txt   draft-ietf-smime-rfc2633bis-08.txt 
Internet Draft Editor: Blake Ramsdell, Internet Draft Editor: Blake Ramsdell,
draft-ietf-smime-rfc2633bis-07.txt Sendmail, Inc. draft-ietf-smime-rfc2633bis-08.txt Sendmail, Inc.
February 15, 2004 March 25, 2004
Expires August 15, 2004 Expires September 25, 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 71 skipping to change at line 72
body parts. body parts.
This specification also discusses how to use the multipart/signed MIME This specification also discusses how to use the multipart/signed MIME
type defined in [MIME-SECURE] to transport S/MIME signed messages. type defined in [MIME-SECURE] to transport S/MIME signed messages.
multipart/signed is used in conjunction with the multipart/signed is used in conjunction with the
application/pkcs7-signature MIME type, which is used to transport application/pkcs7-signature MIME type, which is used to transport
a detached S/MIME signature. a detached S/MIME signature.
In order to create S/MIME messages, an S/MIME agent MUST follow the In order to create S/MIME messages, an S/MIME agent MUST follow the
specifications in this document, as well as the specifications specifications in this document, as well as the specifications
listed in the Cryptographic Message Syntax [CMS]. listed in the Cryptographic Message Syntax document [CMS].
Throughout this specification, there are requirements and Throughout this specification, there are requirements and
recommendations made for how receiving agents handle incoming recommendations made for how receiving agents handle incoming
messages. There are separate requirements and recommendations for how messages. There are separate requirements and recommendations for how
sending agents create outgoing messages. In general, the best strategy sending agents create outgoing messages. In general, the best strategy
is to "be liberal in what you receive and conservative in what you is to "be liberal in what you receive and conservative in what you
send". Most of the requirements are placed on the handling of incoming send". Most of the requirements are placed on the handling of incoming
messages while the recommendations are mostly on the creation of messages while the recommendations are mostly on the creation of
outgoing messages. outgoing messages.
skipping to change at line 108 skipping to change at line 109
For the purposes of this specification, the following definitions For the purposes of this specification, the following definitions
apply. apply.
ASN.1: Abstract Syntax Notation One, as defined in CCITT X.208 ASN.1: Abstract Syntax Notation One, as defined in CCITT X.208
[X.208-88]. [X.208-88].
BER: Basic Encoding Rules for ASN.1, as defined in CCITT X.209 BER: Basic Encoding Rules for ASN.1, as defined in CCITT X.209
[X.209-88]. [X.209-88].
Certificate: A type that binds an entity's distinguished name to a Certificate: A type that binds an entity's name to a public key with a
public key with a digital signature. 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-88]. X.509 [X.509-88].
7-bit data: Text data with lines less than 998 characters long, where 7-bit data: Text data with lines less than 998 characters long, where
none of the characters have the 8th bit set, and there are no NULL none of the characters have the 8th bit set, and there are no NULL
characters. <CR> and <LF> occur only as part of a <CR><LF> end of line characters. <CR> and <LF> occur only as part of a <CR><LF> end of line
delimiter. delimiter.
8-bit data: Text data with lines less than 998 characters, and where 8-bit data: Text data with lines less than 998 characters, and where
none of the characters are NULL characters. <CR> and <LF> occur only none of the characters are NULL characters. <CR> and <LF> occur only
as part of a <CR><LF> end of line delimiter. as part of a <CR><LF> end of line delimiter.
Binary data: Arbitrary data. Binary data: Arbitrary data.
Transfer Encoding: A reversible transformation made on data so 8-bit Transfer Encoding: A reversible transformation made on data so 8-bit
or binary data may be sent via a channel that only transmits 7-bit or binary data may be sent via a channel that only transmits 7-bit
data. data.
Receiving agent: software that interprets and processes S/MIME CMS Receiving agent: Software that interprets and processes S/MIME CMS
objects, MIME body parts that contain CMS 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.1 agents should attempt to have the greatest S/MIME version 3.1 agents should attempt to have the greatest
interoperability possible with agents for prior versions of S/MIME. interoperability possible with agents for prior versions of S/MIME.
S/MIME version 2 is described in RFC 2311 through RFC 2315, inclusive S/MIME version 2 is described in RFC 2311 through RFC 2315, inclusive
and S/MIME version 3 is described in RFC 2630 through RFC 2634 and S/MIME version 3 is described in RFC 2630 through RFC 2634
inclusive. RFC 2311 also has historical information about the inclusive. RFC 2311 also has historical information about the
development of S/MIME. development of S/MIME.
skipping to change at line 172 skipping to change at line 173
The use of binary encoding for some MIME entities is now explicitly The use of binary encoding for some MIME entities is now explicitly
discussed. discussed.
Header protection through the use of the message/rfc822 MIME type has Header protection through the use of the message/rfc822 MIME type has
been added. been added.
Use of the CompressedData CMS type is allowed, along with required Use of the CompressedData CMS type is allowed, along with required
MIME type and file extension additions. MIME type and file extension additions.
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
with the single word
subscribe
in the body of the message. There is a Web site for the mailing list
at <http://www.imc.org/ietf-smime/>.
2. CMS Options 2. CMS Options
CMS allows for a wide variety of options in content and algorithm CMS allows for a wide variety of options in content and algorithm
support. This section puts forth a number of support requirements and support. This section puts forth a number of support requirements and
recommendations in order to achieve a base level of interoperability recommendations in order to achieve a base level of interoperability
among all S/MIME implementations. [CMS] provides additional details among all S/MIME implementations. [CMSALG] provides additional details
regarding the use of the cryptographic algorithms. regarding the use of the cryptographic algorithms.
2.1 DigestAlgorithmIdentifier 2.1 DigestAlgorithmIdentifier
Sending and receiving agents MUST support SHA-1 [CMSALG]. Receiving Sending and receiving agents MUST support SHA-1 [CMSALG]. Receiving
agents SHOULD support MD5 [CMSALG] for the purpose of providing agents SHOULD support MD5 [CMSALG] for the purpose of providing
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 If using rsaEncryption, sending and receiving agents MUST support the
algorithms in section 2.1 as specified. digest 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 required to verify digital signatures using the clients are only required to verify digital signatures using the
rsaEncryption algorithm with SHA-1 or MD5, and may not implement rsaEncryption algorithm with SHA-1 or MD5, and may not implement
id-dsa-with-sha1 at all. id-dsa-with-sha1 or id-dsa 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], using the ephemeral-static mode. [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
skipping to change at line 243 skipping to change at line 230
2.4 General Syntax 2.4 General Syntax
There are several CMS 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
OCTET STRING (unless the sending agent is using multipart/signed, in OCTET STRING (unless the sending agent is using multipart/signed, in
which case the eContent is absent, per section 3.4.3 of this which case the eContent is absent, per section 3.4.3 of this
document). As another example, when applying encryption to MIME data, document). As another example, when applying encryption to MIME data,
the CMS EnvelopedData encryptedContentInfo ContentType MUST include the CMS EnvelopedData encryptedContentInfo contentType MUST include
the id-data object identifier and the encrypted MIME content MUST be the id-data object identifier and the encrypted MIME content MUST be
stored in the envelopedData encryptedContentInfo encryptedContent stored in the EnvelopedData 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. Applying a signature to
a message provides authentication, message integrity, and
non-repudiation of origin.
2.4.3 EnvelopedData Content Type 2.4.3 EnvelopedData Content Type
This content type is used to apply data confidentiality to a message. This content type is used to apply data confidentiality to a message.
A sender needs to have access to a public key for each intended A sender needs to have access to a public key for each intended
message recipient to use this service. This content type does not message recipient to use this service. This content type does not
provide authentication. provide authentication.
2.4.4 CompressedData Content Type 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, message integrity,
used to reduce message size. non-repudiation, or data confidentiality, and is only used to reduce
message size.
See section 3.6 for further guidance on the use of this type in See section 3.6 for further guidance on the use of this type in
conjunction with other CMS types. conjunction with other CMS types.
2.5 Attribute SignerInfo Type 2.5 Attributes and the SignerInfo Type
The SignerInfo type allows the inclusion of unsigned and signed The SignerInfo type allows the inclusion of unsigned and signed
attributes to be included along with a signature. attributes to be included along with a signature.
Receiving agents MUST be able to handle zero or one instance of each Receiving agents MUST be able to handle zero or one instance of each
of the signed attributes listed here. Sending agents SHOULD generate of the signed attributes listed here. Sending agents SHOULD generate
one instance of each of the following signed attributes in each S/MIME one instance of each of the following signed attributes in each S/MIME
message: message:
- signingTime (section 2.5.1 in this document) - signingTime (section 2.5.1 in this document)
skipping to change at line 344 skipping to change at line 334
If present, the SMIMECapabilities attribute MUST be a SignedAttribute; If present, the SMIMECapabilities attribute MUST be a SignedAttribute;
it MUST NOT be an UnsignedAttribute. CMS defines SignedAttributes as a it MUST NOT be an UnsignedAttribute. CMS defines SignedAttributes as a
SET OF Attribute. The SignedAttributes in a signerInfo MUST NOT SET OF Attribute. The SignedAttributes in a signerInfo MUST NOT
include multiple instances of the SMIMECapabilities attribute. CMS include multiple instances of the SMIMECapabilities attribute. CMS
defines the ASN.1 syntax for Attribute to include attrValues SET OF defines the ASN.1 syntax for Attribute to include attrValues SET OF
AttributeValue. A SMIMECapabilities attribute MUST only include a AttributeValue. A SMIMECapabilities attribute MUST only include a
single instance of AttributeValue. There MUST NOT be zero or multiple single instance of AttributeValue. There MUST NOT be zero or multiple
instances of AttributeValue present in the attrValues SET OF instances of AttributeValue present in the attrValues SET OF
AttributeValue. AttributeValue.
The semantics of the SMIMECapabilites attribute specify a partial list The semantics of the SMIMECapabilities attribute specify a partial
as to what the client announcing the SMIMECapabilites can support. A list as to what the client announcing the SMIMECapabilities can
client does not have to list every capability it supports, and support. A client does not have to list every capability it supports,
probably should not list all its capabilities so that the capabilities and probably should not list all its capabilities so that the
list doesn't get too long. In an SMIMECapabilities attribute, the capabilities list doesn't get too long. In an SMIMECapabilities
object identifiers (OIDs) are listed in order of their preference, but attribute, the object identifiers (OIDs) are listed in order of their
SHOULD be logically separated along the lines of their categories preference, but SHOULD be logically separated along the lines of their
(signature algorithms, symmetric algorithms, key encipherment categories (signature algorithms, symmetric algorithms, key
algorithms, etc.) encipherment algorithms, etc.)
The structure of the SMIMECapabilities attribute is to facilitate The structure of the SMIMECapabilities attribute is to facilitate
simple table lookups and binary comparisons in order to determine simple table lookups and binary comparisons in order to determine
matches. For instance, the DER-encoding for the SMIMECapability for matches. For instance, the DER-encoding for the SMIMECapability for
DES EDE3 CBC MUST be identically encoded regardless of the DES EDE3 CBC MUST be identically encoded regardless of the
implementation. Because of the requirement for identical encoding, implementation. Because of the requirement for identical encoding,
individuals documenting algorithms to be used in the SMIMECapabilities individuals documenting algorithms to be used in the SMIMECapabilities
attribute should explicitly document the correct byte sequence for the attribute SHOULD explicitly document the correct byte sequence for the
common cases. common cases.
For any capability, the associated parameters for the OID MUST specify For any capability, the associated parameters for the OID MUST specify
all of the parameters necessary to differentiate between two instances all of the parameters necessary to differentiate between two instances
of the same algorithm. For instance, the number of rounds and block of the same algorithm. For instance, the number of rounds and block
size for RC5 must be specified in addition to the key length. size for RC5 must be specified in addition to the key length.
The OIDs used with S/MIME are assigned in several different RFCs. Note
that all OIDs associated with the MUST and SHOULD implement algorithms
are included in section A of this document.
The OIDs that correspond to algorithms SHOULD use the same OID as the The OIDs that correspond to algorithms SHOULD use the same OID as the
actual algorithm, except in the case where the algorithm usage is actual algorithm, except in the case where the algorithm usage is
ambiguous from the OID. For instance, in an earlier specification, ambiguous from the OID. For instance, in an earlier specification,
rsaEncryption was ambiguous because it could refer to either a rsaEncryption was ambiguous because it could refer to either a
signature algorithm or a key encipherment algorithm. In the event that signature algorithm or a key encipherment algorithm. In the event that
an OID is ambiguous, it needs to be arbitrated by the maintainer of an OID is ambiguous, it needs to be arbitrated by the maintainer of
the registered SMIMECapabilities list as to which type of algorithm the registered SMIMECapabilities list as to which type of algorithm
will use the OID, and a new OID MUST be allocated under the will use the OID, and a new OID MUST be allocated under the
smimeCapabilities OID to satisfy the other use of the OID. smimeCapabilities OID to satisfy the other use of the OID.
skipping to change at line 450 skipping to change at line 436
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. 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.
- If an SMIMEEncryptionKeyPreference attribute is not found in a - If an SMIMEEncryptionKeyPreference attribute is not found in a
signedData object received from the desired recipient, the set of SignedData object received from the desired recipient, the set of
X.509 certificates should be searched for a X.509 certificate with X.509 certificates should be searched for a X.509 certificate with
the same subject name as the signing X.509 certificate which can be the same subject name as the signing X.509 certificate which can be
used for key management. used for key management.
- Or use some other method of determining the user's key management - Or use some other method of determining the user's key management
key. If a X.509 key management certificate is not found, then key. If a X.509 key management certificate is not found, then
encryption cannot be done with the signer of the message. If encryption cannot be done with the signer of the message. If
multiple X.509 key management certificates are found, the S/MIME multiple X.509 key management certificates are found, the S/MIME
agent can make an arbitrary choice between them. agent can make an arbitrary choice between them.
2.6 SignerIdentifier SignerInfo Type 2.6 SignerIdentifier SignerInfo Type
S/MIME v3.1 and S/MIME v3 requires the use of SignerInfo version 1, S/MIME v3.1 implementations MUST support both issuerAndSerialNumber as
that is the issuerAndSerialNumber CHOICE MUST be used for well as subjectKeyIdentifier. Messages that use the
SignerIdentifier. subjectKeyIdentifier choice cannot be read by S/MIME v2 clients.
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.
It is important to understand that some certificates use a value for It is important to understand that some certificates use a value for
subjectKeyIdentifier that is not suitable for uniquely identifying a subjectKeyIdentifier that is not suitable for uniquely identifying a
certificate. Implementations MUST be prepared for multiple certificate. Implementations MUST be prepared for multiple
certificates for potentially different entities to have the same value certificates for potentially different entities to have the same value
for subjectKeyIdentifier, and MUST be prepared to try each matching for subjectKeyIdentifier, and MUST be prepared to try each matching
certificate during signature verification before indicating an error certificate during signature verification before indicating an error
condition. condition.
2.7 ContentEncryptionAlgorithmIdentifier 2.7 ContentEncryptionAlgorithmIdentifier
skipping to change at line 596 skipping to change at line 577
3. Creating S/MIME Messages 3. Creating S/MIME Messages
This section describes the S/MIME message formats and how they are This section describes the S/MIME message formats and how they are
created. S/MIME messages are a combination of MIME bodies and CMS created. S/MIME messages are a combination of MIME bodies and CMS
content types. Several MIME types as well as several CMS content types content types. Several MIME types as well as several CMS content types
are used. The data to be secured is always a canonical MIME entity. are used. The data to be secured is always a canonical MIME entity.
The MIME entity and other data, such as certificates and algorithm The MIME entity and other data, such as certificates and algorithm
identifiers, are given to CMS processing facilities which produces a identifiers, are given to CMS processing facilities which produces a
CMS object. The CMS object is then finally wrapped in MIME. The CMS object. The CMS object is then finally wrapped in MIME. The
Enhanced Security Services for S/MIME [ESS] document provides examples Enhanced Security Services for S/MIME [ESS] document provides
of how nested, secured S/MIME messages are formatted. ESS provides an descriptions of how nested, secured S/MIME messages are formatted. ESS
example of how a triple-wrapped S/MIME message is formatted using provides a description of how a triple-wrapped S/MIME message is
multipart/signed and application/pkcs7-mime for the signatures. formatted using multipart/signed and application/pkcs7-mime for the
signatures.
S/MIME provides one format for enveloped-only data, several formats S/MIME provides one format for enveloped-only data, several formats
for signed-only data, and several formats for signed and enveloped for signed-only data, and several formats for signed and enveloped
data. Several formats are required to accommodate several data. Several formats are required to accommodate several
environments, in particular for signed messages. The criteria for environments, in particular for signed messages. The criteria for
choosing among these formats are also described. choosing among these formats are also described.
The reader of this section is expected to understand MIME as described The reader of this section is expected to understand MIME as described
in [MIME-SPEC] and [MIME-SECURE]. in [MIME-SPEC] and [MIME-SECURE].
3.1 Preparing the MIME Entity for Signing or Enveloping 3.1 Preparing the MIME Entity for Signing, Enveloping or Compressing
S/MIME is used to secure MIME entities. A MIME entity may be a sub- S/MIME is used to secure MIME entities. A MIME entity may be a sub-
part, sub-parts of a message, or the whole message with all its sub- part, sub-parts of a message, or the whole message with all its sub-
parts. A MIME entity that is the whole message includes only the MIME parts. A MIME entity that is the whole message includes only the MIME
headers and MIME body, and does not include the RFC-822 headers. Note headers and MIME body, and does not include the RFC-822 headers. Note
that S/MIME can also be used to secure MIME entities used in that S/MIME can also be used to secure MIME entities used in
applications other than Internet mail. If protection of the RFC-822 applications other than Internet mail. If protection of the RFC-822
headers is required, the use of the message/rfc822 MIME type is headers is required, the use of the message/rfc822 MIME type is
explained later in this section. explained later in this section.
skipping to change at line 633 skipping to change at line 615
object in what is possibly a larger MIME message. Processing "outside" object in what is possibly a larger MIME message. Processing "outside"
MIME entities into CMS content types is described in Section 3.2, 3.4 MIME entities into CMS content types is described in Section 3.2, 3.4
and elsewhere. and elsewhere.
The procedure for preparing a MIME entity is given in [MIME-SPEC]. The The procedure for preparing a MIME entity is given in [MIME-SPEC]. The
same procedure is used here with some additional restrictions when same procedure is used here with some additional restrictions when
signing. Description of the procedures from [MIME-SPEC] are repeated signing. Description of the procedures from [MIME-SPEC] are repeated
here, but the reader should refer to that document for the exact here, but the reader should refer to that document for the exact
procedure. This section also describes additional requirements. procedure. This section also describes additional requirements.
A single procedure is used for creating MIME entities that are to be A single procedure is used for creating MIME entities that are to have
signed, enveloped, or both signed and enveloped. Some additional steps any combination of signing, enveloping and compressing applied. Some
are recommended to defend against known corruptions that can occur additional steps are recommended to defend against known corruptions
during mail transport that are of particular importance for clear- that can occur during mail transport that are of particular importance
signing using the multipart/signed format. It is recommended that for clear- signing using the multipart/signed format. It is
these additional steps be performed on enveloped messages, or signed recommended that these additional steps be performed on enveloped
and enveloped messages in order that the message can be forwarded to messages, or signed and enveloped messages in order that the message
any environment without modification. can be forwarded to any environment without modification.
These steps are descriptive rather than prescriptive. The implementor These steps are descriptive rather than prescriptive. The implementer
is free to use any procedure as long as the result is the same. is free to use any procedure as long as the result is the same.
Step 1. The MIME entity is prepared according to the local conventions Step 1. The MIME entity is prepared according to the local
conventions.
Step 2. The leaf parts of the MIME entity are converted to canonical Step 2. The leaf parts of the MIME entity are converted to canonical
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.
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
skipping to change at line 751 skipping to change at line 734
constrained to 7-bit text, it MUST have transfer encoding applied so constrained to 7-bit text, it MUST have transfer encoding applied so
that it is represented as 7-bit text. MIME entities that are 7-bit that it is represented as 7-bit text. MIME entities that are 7-bit
data already need no transfer encoding. Entities such as 8-bit text data already need no transfer encoding. Entities such as 8-bit text
and binary data can be encoded with quoted-printable or base-64 and binary data can be encoded with quoted-printable or base-64
transfer encoding. transfer encoding.
The primary reason for the 7-bit requirement is that the Internet mail The primary reason for the 7-bit requirement is that the Internet mail
transport infrastructure cannot guarantee transport of 8-bit or binary transport infrastructure cannot guarantee transport of 8-bit or binary
data. Even though many segments of the transport infrastructure now data. Even though many segments of the transport infrastructure now
handle 8-bit and even binary data, it is sometimes not possible to handle 8-bit and even binary data, it is sometimes not possible to
know whether the transport path is 8-bit clear. If a mail message with know whether the transport path is 8-bit clean. If a mail message with
8-bit data were to encounter a message transfer agent that can not 8-bit data were to encounter a message transfer agent that can not
transmit 8-bit or binary data, the agent has three options, none of transmit 8-bit or binary data, the agent has three options, none of
which are acceptable for a clear-signed message: which are acceptable for a clear-signed message:
- The agent could change the transfer encoding; this would invalidate - The agent could change the transfer encoding; this would invalidate
the signature. the signature.
- The agent could transmit the data anyway, which would most likely - The agent could transmit the data anyway, which would most likely
result in the 8th bit being corrupted; this too would invalidate the result in the 8th bit being corrupted; this too would invalidate the
signature. signature.
- The agent could return the message to the sender. - The agent could return the message to the sender.
skipping to change at line 813 skipping to change at line 796
iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC// iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
HOxEa44b+EI= HOxEa44b+EI=
--bar-- --bar--
3.2 The application/pkcs7-mime Type 3.2 The application/pkcs7-mime Type
The application/pkcs7-mime type is used to carry CMS content types The application/pkcs7-mime type is used to carry CMS content types
including envelopedData, signedData and compressedData. The details of including EnvelopedData, SignedData and CompressedData. The details of
constructing these entities is described in subsequent sections. This constructing these entities is described in subsequent sections. This
section describes the general characteristics of the section describes the general characteristics of the
application/pkcs7-mime type. application/pkcs7-mime type.
The carried CMS object always contains a MIME entity that is prepared The carried CMS object always contains a MIME entity that is prepared
as described in section 3.1 if the eContentType is id-data. Other as described in section 3.1 if the eContentType is id-data. Other
contents may be carried when the eContentType contains different contents may be carried when the eContentType contains different
values. See [ESS] for an example of this with signed receipts. values. See [ESS] for an example of this with signed receipts.
Since CMS content types are binary data, in most cases base-64 Since CMS content types are binary data, in most cases base-64
skipping to change at line 852 skipping to change at line 835
For the application/pkcs7-mime, sending agents SHOULD emit the For the application/pkcs7-mime, sending agents SHOULD emit the
optional "name" parameter to the Content-Type field for compatibility optional "name" parameter to the Content-Type field for compatibility
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
certificate management message) certificate management message)
Application/pkcs7-mime (compressedData) .p7z Application/pkcs7-mime (CompressedData) .p7z
Application/pkcs7-signature .p7s Application/pkcs7-signature (SignedData) .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
of S/MIME objects as files on disk. It also can convey type of S/MIME objects as files on disk. It also can convey type
information across gateways. When a MIME entity of type information across gateways. When a MIME entity of type
skipping to change at line 933 skipping to change at line 916
This section describes the format for enveloping a MIME entity without This section describes the format for enveloping a MIME entity without
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 envelopedData object is wrapped in a CMS ContentInfo Step 3. The EnvelopedData object is wrapped in a CMS ContentInfo
object. object.
Step 4. The ContentInfo object is inserted into an Step 4. The ContentInfo object is inserted into an
application/pkcs7-mime MIME entity. 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:
skipping to change at line 982 skipping to change at line 965
receivers without S/MIME software being able to view the message. receivers without S/MIME software being able to view the message.
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, the signedData recipient unless they have S/MIME facilities. However, the SignedData
format protects the message content from being changed by benign format protects the message content from being changed by benign
intermediate agents. Such agents might do line wrapping or intermediate agents. Such agents might do line wrapping or
content-transfer encoding changes which would break the signature. 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.
Step 3. The signedData object is wrapped in a CMS ContentInfo Step 3. The SignedData object is wrapped in a CMS ContentInfo
object. object.
Step 4. The ContentInfo object is inserted into an Step 4. The ContentInfo object is inserted into an
application/pkcs7-mime MIME entity. 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:
skipping to change at line 1033 skipping to change at line 1016
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 CMS ContentInfo containing a single This MIME type always contains a CMS ContentInfo containing a single
CMS object of type signedData. The signedData encapContentInfo CMS object of type SignedData. The SignedData encapContentInfo
eContent field MUST be absent. The signerInfos field contains the eContent field MUST be absent. The signerInfos field contains the
signatures for the MIME entity. 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
obtain an object of type signedData in which the encapContentInfo obtain an object of type SignedData in which the encapContentInfo
eContent field is absent. eContent field is absent.
Step 3. The MIME entity is inserted into the first part of a Step 3. The MIME entity is inserted into the first part of a
multipart/signed message with no processing other than that described multipart/signed message with no processing other than that described
in section 3.1. in section 3.1.
Step 4. Transfer encoding is applied to the "detached signature" CMS Step 4. Transfer encoding is applied to the "detached signature" CMS
SignedData object and it is inserted into a MIME entity of type SignedData object and it is inserted into a MIME entity of type
application/pkcs7-signature. application/pkcs7-signature.
skipping to change at line 1092 skipping to change at line 1075
SHA-512 sha512 SHA-512 sha512
Any other (defined separately in algorithm profile or "unknown" Any other (defined separately in algorithm profile or "unknown"
if not defined) 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 recommended in S/MIME, and are included here for completeness.
3.4.3.3 Sample multipart/signed Message 3.4.3.3 Sample multipart/signed Message
Content-Type: multipart/signed; Content-Type: multipart/signed;
protocol="application/pkcs7-signature"; protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42 micalg=sha1; boundary=boundary42
--boundary42 --boundary42
Content-Type: text/plain Content-Type: text/plain
skipping to change at line 1128 skipping to change at line 1111
are the bytes: 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 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 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 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 compressed 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 compressedData. CMS object of type CompressedData.
Step 3. The compressedData object is wrapped in a CMS ContentInfo Step 3. The CompressedData object is wrapped in a CMS ContentInfo
object. object.
Step 4. The ContentInfo object is inserted into an Step 4. The ContentInfo object is inserted into an
application/pkcs7-mime MIME entity. application/pkcs7-mime MIME entity.
The smime-type parameter for compressed-only messages is "compressed- The smime-type parameter for compressed-only messages is "compressed-
data". The file extension for this type of message is ".p7z". data". The file extension for this type of message is ".p7z".
A sample message would be: A sample message would be:
skipping to change at line 1170 skipping to change at line 1153
The signed-only, encrypted-only, and compressed-only MIME formats can The signed-only, encrypted-only, and compressed-only MIME formats can
be nested. This works because these formats are all MIME entities that be nested. This works because these formats are all MIME entities that
encapsulate other MIME entities. encapsulate other 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 apply any of the signing, encrypting and compressing It is possible to apply any of the signing, encrypting and compressing
operations in any order. It is up to the implementor and the user to operations in any order. It is up to the implementer and the user to
choose. When signing first, the signatories are then securely obscured choose. When signing first, the signatories are then securely obscured
by the enveloping. When enveloping first the signatories are exposed, by the enveloping. When enveloping first the signatories are exposed,
but it is possible to verify signatures without removing the but it is possible to verify signatures without removing the
enveloping. This may be useful in an environment were automatic enveloping. This may be useful in an environment were automatic
signature verification is desired, as no private key material is signature verification is desired, as no private key material is
required to verify a signature. required to verify a signature.
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
skipping to change at line 1203 skipping to change at line 1186
to compress first, then sign. to compress first, then sign.
3.7 Creating a Certificate Management Message 3.7 Creating a Certificate Management Message
The certificate management message or MIME entity is used to transport The certificate management message or MIME entity is used to transport
certificates and/or certificate revocation lists, such as in response certificates and/or certificate revocation lists, such as in response
to a registration request. to a registration request.
Step 1. The certificates and/or certificate revocation lists are made Step 1. The certificates and/or certificate revocation lists are made
available to the CMS generating process which creates a CMS object of available to the CMS generating process which creates a CMS object of
type signedData. The signedData encapContentInfo eContent field MUST type SignedData. The SignedData encapContentInfo eContent field MUST
be absent and signerInfos field MUST be empty. be absent and signerInfos field MUST be empty.
Step 2. The signedData object is wrapped in a CMS ContentInfo Step 2. The SignedData object is wrapped in a CMS ContentInfo
object. object.
Step 3. The ContentInfo object is enclosed in an application/pkcs7- Step 3. The ContentInfo object is enclosed in an application/pkcs7-
mime MIME entity mime MIME entity.
The smime-type parameter for a certificate management message is The smime-type parameter for a certificate management message is
"certs-only". The file extension for this type of message is ".p7c". "certs-only". The file extension for this type of message is ".p7c".
3.8 Registration Requests 3.8 Registration Requests
A sending agent that signs messages MUST have a certificate for the A sending agent that signs messages MUST have a certificate for the
signature so that a receiving agent can verify the signature. There signature so that a receiving agent can verify the signature. There
are many ways of getting certificates, such as through an exchange are many ways of getting certificates, such as through an exchange
with a certificate authority, through a hardware token or diskette, with a certificate authority, through a hardware token or diskette,
skipping to change at line 1261 skipping to change at line 1244
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 [CERT31]. or rejected. S/MIME certificate 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
skipping to change at line 1287 skipping to change at line 1270
agent or some related administrative utility or function SHOULD agent or some related administrative utility or function SHOULD
generate RSA key pairs using the following guidelines. A user agent 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 SHOULD generate RSA key pairs at a minimum key size of 768 bits. A
user agent MUST NOT generate RSA key pairs less than 512 bits long. user agent MUST NOT generate RSA key pairs less than 512 bits long.
Creating keys longer than 1024 bits may cause some older S/MIME Creating keys longer than 1024 bits may cause some older S/MIME
receiving agents to not be able to verify signatures, but gives better receiving agents to not be able to verify signatures, but gives better
security and is therefore valuable. A receiving agent SHOULD be able security and is therefore valuable. A receiving agent SHOULD be able
to verify signatures with keys of any size over 512 bits. Some agents to verify signatures with keys of any size over 512 bits. Some agents
created in the United States have chosen to create 512 bit keys in created in the United States have chosen to create 512 bit keys in
order to get more advantageous export licenses. However, 512 bit keys order to get more advantageous export licenses. However, 512 bit keys
are considered by many to be cryptographically insecure. Implementors are considered by many to be cryptographically insecure. Implementers
should be aware that multiple (active) key pairs may be associated should be aware that multiple (active) key pairs may be associated
with a single individual. For example, one key pair may be used to with a single individual. For example, one key pair may be used to
support confidentiality, while a different key pair may be used for support confidentiality, while a different key pair may be used for
authentication. 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
skipping to change at line 1375 skipping to change at line 1358
smimeCapabilities OBJECT IDENTIFIER ::= smimeCapabilities OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15} {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15}
SMIMECapability ::= SEQUENCE { SMIMECapability ::= SEQUENCE {
capabilityID OBJECT IDENTIFIER, capabilityID OBJECT IDENTIFIER,
parameters ANY DEFINED BY capabilityID OPTIONAL } parameters ANY DEFINED BY capabilityID OPTIONAL }
SMIMECapabilities ::= SEQUENCE OF SMIMECapability SMIMECapabilities ::= SEQUENCE OF SMIMECapability
-- Encryption Key Preference provides a method of broadcasting the -- Encryption Key Preference provides a method of broadcasting the
-- preferred 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
} }
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
skipping to change at line 1427 skipping to change at line 1410
[CERT31] "S/MIME Version 3.1 Certificate Handling", Internet Draft [CERT31] "S/MIME Version 3.1 Certificate Handling", Internet Draft
draft-ietf-smime-rfc2632bis draft-ietf-smime-rfc2632bis
[CHARSETS] Character sets assigned by IANA. See <ftp://ftp.isi.edu/in- [CHARSETS] Character sets assigned by IANA. See <ftp://ftp.isi.edu/in-
notes/iana/assignments/character-sets>. notes/iana/assignments/character-sets>.
[CMS] "Cryptographic Message Syntax", RFC 3369 [CMS] "Cryptographic Message Syntax", RFC 3369
[CMSAES] "Use of the AES Encryption Algorithm in CMS", [CMSAES] "Use of the AES Encryption Algorithm in CMS",
draft-ietf-smime-aes-alg-07
[CMSALG] "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370 [CMSALG] "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370
[CMSCOMPR] "Compressed Data Content Type for Cryptographic Message [CMSCOMPR] "Compressed Data Content Type for Cryptographic Message
Syntax (CMS)", RFC 3274 Syntax (CMS)", RFC 3274
[CONTDISP] "Communicating Presentation Information in Internet [CONTDISP] "Communicating Presentation Information in Internet
Messages: The Content-Disposition Header Field", RFC 2183 Messages: The Content-Disposition Header Field", RFC 2183
[ESS] "Enhanced Security Services for S/MIME", RFC 2634 [ESS] "Enhanced Security Services for S/MIME", RFC 2634
skipping to change at line 1507 skipping to change at line 1489
Jim Schaad Jim Schaad
E. Editor's address E. Editor's address
Blake Ramsdell Blake Ramsdell
Sendmail, Inc. Sendmail, Inc.
704 228th Ave NE #775 704 228th Ave NE #775
Sammamish, WA 98074 Sammamish, WA 98074
blake@sendmail.com blake@sendmail.com
F. Changes from last draft
Updated editor contact info (Blake Ramsdell)
Separated normative and informative references (Jim Schaad)
Added language clarifying non-uniqueness of subjectKeyIdentifier (List
discussion)
smime-type clarifications (List discussion)
RC2 S/MIME capability documented (Jim Schaad)
 End of changes. 

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