draft-ietf-smime-msg-05.txt   draft-ietf-smime-msg-06.txt 
Internet Draft Editor: Blake Ramsdell, Internet Draft Editor: Blake Ramsdell,
draft-ietf-smime-msg-05.txt Worldtalk draft-ietf-smime-msg-06.txt Worldtalk
August 6, 1998 December 14, 1998
Expires in six months Expires in six months
S/MIME Version 3 Message Specification S/MIME Version 3 Message Specification
Status of this memo Status of this memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at line 65 skipping to change at line 65
This draft defines how to create a MIME body part that has been This draft defines how to create a MIME body part that has been
cryptographically enhanced according to CMS [CMS], which is derived cryptographically enhanced according to CMS [CMS], which is derived
from PKCS #7 [PKCS-7]. This draft also defines the application/pkcs7- from PKCS #7 [PKCS-7]. This draft also defines the application/pkcs7-
mime MIME type that can be used to transport those body parts. 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 draft also discusses how to use the multipart/signed MIME type
defined in [MIME-SECURE] to transport S/MIME signed messages. This defined in [MIME-SECURE] to transport S/MIME signed messages. This
draft also defines the application/pkcs7-signature MIME type, which is draft also defines the application/pkcs7-signature MIME type, which is
also used to transport S/MIME signed messages. also used to transport S/MIME signed messages.
In order to create S/MIME messages, an agent has to follow In order to create S/MIME messages, an S/MIME agent has to follow
specifications in this draft, as well as the specifications listed in specifications in this draft, as well as the specifications listed in
the Cryptographic Message Syntax [CMS]. the Cryptographic Message Syntax [CMS].
Throughout this draft, there are requirements and recommendations made Throughout this draft, there are requirements and recommendations made
for how receiving agents handle incoming messages. There are separate for how receiving agents handle incoming messages. There are separate
requirements and recommendations for how sending agents create requirements and recommendations for how sending agents create
outgoing messages. In general, the best strategy is to "be liberal in outgoing messages. In general, the best strategy is to "be liberal in
what you receive and conservative in what you send". Most of the what you receive and conservative in what you send". Most of the
requirements are placed on the handling of incoming messages while the requirements are placed on the handling of incoming messages while the
recommendations are mostly on the creation of outgoing messages. recommendations are mostly on the creation of outgoing messages.
skipping to change at line 124 skipping to change at line 124
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
objects, MIME body parts that contain CMS objects, or both.
Sending agent: software that creates S/MIME CMS objects, MIME body
parts that contain CMS objects, or both.
S/MIME agent: user software that is a receiving agent, a sending
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 Discussion of This Draft
This draft is being discussed on the "ietf-smime" mailing list. To This draft is being discussed on the "ietf-smime" mailing list. To
skipping to change at line 220 skipping to change at line 229
sender needs to have access to a public key for each sender needs to have access to a public key for each
intended message recipient to use this service. This content type does intended message recipient to use this service. This content type does
not provide authentication. not 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 described in this section. of the signed attributes listed here. Sending agents SHOULD generate
one instance of each of the following signed attributes in each S/MIME
message:
- signingTime (section 2.5.1 in this document)
- sMIMECapabilities (section 2.5.2 in this document)
- sMIMEEncryptionKeyPreference (section 2.5.3 in this document)
Sending agents SHOULD be able to generate one instance of each of the Further, receiving agents SHOULD be able to handle zero or one
signed attributes described in this section, and SHOULD include the instance of each of the signed attributes listed here.
signing time and SMIMECapabilities attribute in each signed message - receiptRequest (section 2 in [ESS])
sent. - signingCertificate (section 5 in [ESS])
Sending agents SHOULD generate one instance of the signingCertificate
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 attributes that are not listed here SHOULD Sending agents that include signed attributes that are not listed here
display those attributes to the user, so that the user is aware of all SHOULD display those attributes to the user, so that the user is aware
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. Until there are trusted timestamping services, the time of
signing will most likely be created by a message originator and signing will most likely be created by a message originator and
therefore is only as trustworthy as the originator. therefore is only as trustworthy as the originator.
Sending agents MUST encode signing time through the year 2049 as Sending agents MUST encode signing time through the year 2049 as
UTCTime; signing times in 2050 or later MUST be encoded as UTCTime; signing times in 2050 or later MUST be encoded as
GeneralizedTime. When the UTCTime CHOICE is used, 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
The SMIMECapabilities attribute includes signature algorithms (such as The SMIMECapabilities attribute includes signature algorithms (such as
"md5WithRSAEncryption"), symmetric algorithms (such as "DES-CBC"), and "sha1WithRSAEncryption"), symmetric algorithms (such as "DES-EDE3-
key encipherment algorithms (such as "rsaEncryption"). It also CBC"), and key encipherment algorithms (such as "rsaEncryption"). It
includes a non-algorithm capability which is the preference for also includes a non-algorithm capability which is the preference for
signedData. The SMIMECapabilities were designed to be flexible and signedData. The SMIMECapabilities were designed to be flexible and
extensible so that, in the future, a means of identifying other extensible so that, in the future, a means of identifying other
capabilities and preferences such as certificates can be added in a capabilities and preferences such as certificates can be added in a
way that will not cause current clients to break. way that will not cause current clients to break.
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
skipping to change at line 292 skipping to change at line 309
matches. For instance, the DER-encoding for the SMIMECapability for matches. For instance, the DER-encoding for the SMIMECapability for
DES EDE3 CBC MUST be identically encoded regardless of the DES EDE3 CBC MUST be identically encoded regardless of the
implementation. implementation.
In the case of symmetric algorithms, the associated parameters for the In the case of symmetric algorithms, the associated parameters for the
OID MUST specify all of the parameters necessary to differentiate OID MUST specify all of the parameters necessary to differentiate
between two instances of the same algorithm. For instance, the number between two instances of the same algorithm. For instance, the number
of rounds and block size for RC5 must be specified in addition to the of rounds and block size for RC5 must be specified in addition to the
key length. key length.
There is a list of OIDs (the registered SMIMECapabilities list) that There is a list of OIDs (OIDs Used with S/MIME) that is centrally
is centrally maintained and is separate from this draft. The list of maintained and is separate from this draft. The list of OIDs is
OIDs is maintained by the Internet Mail Consortium at maintained by the Internet Mail Consortium at <http://www.imc.org/ietf-
<http://www.imc.org/ietf-smime/oids.html>. smime/oids.html>.
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 draft,
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 319 skipping to change at line 336
length symmetric ciphers. In the event that there are no length symmetric ciphers. In the event that there are no
differentiating parameters for a particular OID, the parameters MUST differentiating parameters for a particular OID, the parameters MUST
be omitted, and MUST NOT be encoded as NULL. be omitted, and MUST NOT be encoded as NULL.
Additional values for the SMIMECapabilities attribute may be defined Additional values for the SMIMECapabilities attribute may be defined
in the future. Receiving agents MUST handle a SMIMECapabilities object in the future. Receiving agents MUST handle a SMIMECapabilities object
that has values that it does not recognize in a graceful manner. that has values that it does not recognize in a graceful manner.
2.5.3 Encryption Key Preference Attribute 2.5.3 Encryption Key Preference Attribute
The encryption key preference attribute allows for the signer to The encryption key preference attribute allows the signer to
unambiguously describe which of the certificates issued to the signer unambiguously describe which of the signer's certificates has the
should be used when sending encrypted content. This attribute allows signer's preferred encryption key. This attribute is designed to
for the signer to state a preference, but not a requirement, as to the enhance behavior for interoperating with those clients which use
certificate to be used. This attribute is designed to enhance separate keys for encryption and signing. This attribute is used to
behavior for interoperating with those clients which use separate keys convey to anyone viewing the attribute which of the listed
for encryption and signing. This attribute is used to convey to the certificates should be used for encrypting a session key for future
receiver which of the certificates should be used for encrypting the encrypted messages.
session key.
If present, the SMIMEEncryptionKeyPreference attribute MUST be a If present, the SMIMEEncryptionKeyPreference attribute MUST be a
SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines
SignedAttributes as a SET OF Attribute. The SignedAttributes in a SignedAttributes as a SET OF Attribute. The SignedAttributes in a
signerInfo MUST NOT include multiple instances of the signerInfo MUST NOT include multiple instances of the
SMIMEEncryptionKeyPreference attribute. CMS defines the ASN.1 syntax SMIMEEncryptionKeyPreference attribute. CMS defines the ASN.1 syntax
for Attribute to include attrValues SET OF AttributeValue. A for Attribute to include attrValues SET OF AttributeValue. A
SMIMEEncryptionKeyPreference attribute MUST only include a single SMIMEEncryptionKeyPreference attribute MUST only include a single
instance of AttributeValue. There MUST NOT be zero or multiple 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
skipping to change at line 350 skipping to change at line 366
The sending agent SHOULD include the referenced certificate in the set The sending agent SHOULD include the referenced certificate in the set
of certificates included in the signed message if this attribute is of certificates included in the signed message if this attribute is
used. The certificate may be omitted if it has been previously made used. The certificate may be omitted if it has been previously made
available to the receiving agent. Sending agents SHOULD use this available to the receiving agent. Sending agents SHOULD use this
attribute if the commonly used or preferred encryption certificate is attribute if the commonly used or preferred encryption certificate is
not the same as the certificate used to sign the message. not the same as the certificate used to sign the message.
Receiving agents SHOULD store the preference data if the signature on Receiving agents SHOULD store the preference data if the signature on
the message is valid and the signing time is greater than the the message is valid and the signing time is greater than the
currently stored value. (As with the SMIMECapabilities, the clock currently stored value. (As with the SMIMECapabilities, the clock
skew should be checked and the data not used if the skew is to great.) skew should be checked and the data not used if the skew is too
Receiving agents SHOULD respect the senders encryption key preference great.) Receiving agents SHOULD respect the sender's encryption key
attribute if possible. This however represents only a preference and preference attribute if possible. This however represents only a
the receiving agent may use any certificate in replying to the sender preference and the receiving agent may use any certificate in replying
that is valid. to the sender that is valid.
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 CMS envelopedData message for a particular recipient, the sending a future CMS envelopedData message for a particular recipient,
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 identifies signedData object received from the desired recipient, this identifies
the X.509 certificate that should be used as the X.509 key management the X.509 certificate that should be used as the X.509 key management
certificate for the recipient. 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 the 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 used same subject name as the signing X.509 certificate which can be used
for key management. 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 multiple encryption cannot be done with the signer of the message. If multiple
X.509 key management certificates are found, the S/MIME agent can make X.509 key management certificates are found, the S/MIME agent can make
an arbitrary choice between them. an arbitrary choice between them.
2.6 ContentEncryptionAlgorithmIdentifier 2.6 SignerIdentifier SignerInfo Type
S/MIME v3 requires the use of SignerInfo version 1, that is the
issuerAndSerialNumber CHOICE must be used for SignerIdentifier.
2.7 ContentEncryptionAlgorithmIdentifier
Sending and receiving agents MUST support encryption and decryption Sending and receiving agents MUST support encryption and decryption
with DES EDE3 CBC, hereinafter called "tripleDES" [3DES] [DES]. with DES EDE3 CBC, hereinafter called "tripleDES" [3DES] [DES].
Receiving agents SHOULD support encryption and decryption using the Receiving agents SHOULD support encryption and decryption using the
RC2 [RC2] or a compatible algorithm at a key size of 40 bits, RC2 [RC2] or a compatible algorithm at a key size of 40 bits,
hereinafter called "RC2/40". hereinafter called "RC2/40".
2.6.1 Deciding Which Encryption Method To Use 2.7.1 Deciding Which Encryption Method To Use
When a sending agent creates an encrypted message, it has to decide When a sending agent creates an encrypted message, it has to decide
which type of encryption to use. The decision process involves using which type of encryption to use. The decision process involves using
information garnered from the capabilities lists included in messages information garnered from the capabilities lists included in messages
received from the recipient, as well as out-of-band information such received from the recipient, as well as out-of-band information such
as private agreements, user preferences, legal restrictions, and so as private agreements, user preferences, legal restrictions, and so
on. on.
Section 2.5 defines a method by which a sending agent can optionally Section 2.5 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
skipping to change at line 427 skipping to change at line 448
messages. messages.
Before sending a message, the sending agent MUST decide whether it is Before sending a message, the sending agent MUST decide whether it is
willing to use weak encryption for the particular data in the message. willing to use weak encryption for the particular data in the message.
If the sending agent decides that weak encryption is unacceptable for If the sending agent decides that weak encryption is unacceptable for
this data, then the sending agent MUST NOT use a weak algorithm such this data, then the sending agent MUST NOT use a weak algorithm such
as RC2/40. The decision to use or not use weak encryption overrides as RC2/40. The decision to use or not use weak encryption overrides
any other decision in this section about which encryption algorithm to any other decision in this section about which encryption algorithm to
use. use.
Sections 2.6.2.1 through 2.6.2.4 describe the decisions a sending Sections 2.7.2.1 through 2.7.2.4 describe the decisions a sending
agent SHOULD use in deciding which type of encryption should be agent SHOULD use in deciding which type of encryption should be
applied to a message. These rules are ordered, so the sending agent applied to a message. These rules are ordered, so the sending agent
SHOULD make its decision in the order given. SHOULD make its decision in the order given.
2.6.1.1 Rule 1: Known Capabilities 2.7.1.1 Rule 1: Known Capabilities
If the sending agent has received a set of capabilities from the If the sending agent has received a set of capabilities from the
recipient for the message the agent is about to encrypt, then the recipient for the message the agent is about to encrypt, then the
sending agent SHOULD use that information by selecting the first sending agent SHOULD use that information by selecting the first
capability in the list (that is, the capability most preferred by the capability in the list (that is, the capability most preferred by the
intended recipient) for which the sending agent knows how to encrypt. intended recipient) for which the sending agent knows how to encrypt.
The sending agent SHOULD use one of the capabilities in the list if The sending agent SHOULD use one of the capabilities in the list if
the agent reasonably expects the recipient to be able to decrypt the the agent reasonably expects the recipient to be able to decrypt the
message. message.
2.6.1.2 Rule 2: Unknown Capabilities, Known Use of Encryption 2.7.1.2 Rule 2: Unknown Capabilities, Known Use of Encryption
If: If:
- the sending agent has no knowledge of the encryption capabilities - the sending agent has no knowledge of the encryption capabilities
of the recipient, of the recipient,
- and the sending agent has received at least one message from the - and the sending agent has received at least one message from the
recipient, recipient,
- and the last encrypted message received from the recipient had a - and the last encrypted message received from the recipient had a
trusted signature on it, trusted signature on it,
then the outgoing message SHOULD use the same encryption algorithm as then the outgoing message SHOULD use the same encryption algorithm as
was used on the last signed and encrypted message received from the was used on the last signed and encrypted message received from the
recipient. recipient.
2.6.1.3 Rule 3: Unknown Capabilities, Unknown Version of S/MIME 2.7.1.3 Rule 3: Unknown Capabilities, Unknown Version of S/MIME
If: If:
- the sending agent has no knowledge of the encryption capabilities - the sending agent has no knowledge of the encryption capabilities
of the recipient, of the recipient,
- and the sending agent has no knowledge of the version of S/MIME - and the sending agent has no knowledge of the version of S/MIME
of the recipient, of the recipient,
then the sending agent SHOULD use tripleDES because it is a stronger then the sending agent SHOULD use tripleDES because it is a stronger
algorithm and is required by S/MIME v3. If the sending agent chooses algorithm and is required by S/MIME v3. If the sending agent chooses
not to use tripleDES in this step, it SHOULD use RC2/40. not to use tripleDES in this step, it SHOULD use RC2/40.
2.6.2 Choosing Weak Encryption 2.7.2 Choosing Weak Encryption
Like all algorithms that use 40 bit keys, RC2/40 is considered by many Like all algorithms that use 40 bit keys, RC2/40 is considered by many
to be weak encryption. A sending agent that is controlled by a human to be weak encryption. A sending agent that is controlled by a human
SHOULD allow a human sender to determine the risks of sending data SHOULD allow a human sender to determine the risks of sending data
using RC2/40 or a similarly weak encryption algorithm before sending using RC2/40 or a similarly weak encryption algorithm before sending
the data, and possibly allow the human to use a stronger encryption the data, and possibly allow the human to use a stronger encryption
method such as tripleDES. method such as tripleDES.
2.6.3 Multiple Recipients 2.7.3 Multiple Recipients
If a sending agent is composing an encrypted message to a group of If a sending agent is composing an encrypted message to a group of
recipients where the encryption capabilities of some of the recipients recipients where the encryption capabilities of some of the recipients
do not overlap, the sending agent is forced to send more than one do not overlap, the sending agent is forced to send more than one
message. It should be noted that if the sending agent chooses to send message. It should be noted that if the sending agent chooses to send
a message encrypted with a strong algorithm, and then send the same a message encrypted with a strong algorithm, and then send the same
message encrypted with a weak algorithm, someone watching the message encrypted with a weak algorithm, someone watching the
communications channel can decipher the contents of the strongly- communications channel can decipher the contents of the strongly-
encrypted message simply by decrypting the weakly-encrypted message. encrypted message simply by decrypting the weakly-encrypted message.
skipping to change at line 571 skipping to change at line 592
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
standard for the particular MIME type should be consulted. For standard for the particular MIME type should be consulted. For
example, canonicalization of type text/plain is different from example, canonicalization of type text/plain is different from
canonicalization of audio/basic. Other than text types, most types canonicalization of audio/basic. Other than text types, most types
have only one representation regardless of computing platform or have only one representation regardless of computing platform or
environment which can be considered their canonical representation. In environment which can be considered their canonical representation. In
general, canonicalization will be performed by the sending agent general, canonicalization will be performed by the non-security part
rather than the S/MIME implementation. of the sending agent rather than the S/MIME implementation.
The most common and important canonicalization is for text, which is The most common and important canonicalization is for text, which is
often represented differently in different environments. MIME entities often represented differently in different environments. MIME entities
of major type "text" must have both their line endings and character of major type "text" must have both their line endings and character
set canonicalized. The line ending must be the pair of characters set canonicalized. The line ending must be the pair of characters
<CR><LF>, and the charset should be a registered charset [CHARSETS]. <CR><LF>, and the charset should be a registered charset [CHARSETS].
The details of the canonicalization are specified in [MIME-SPEC]. The The details of the canonicalization are specified in [MIME-SPEC]. The
chosen charset SHOULD be named in the charset parameter so that chosen charset SHOULD be named in the charset parameter so that
the receiving agent can unambiguously determine the charset used. the receiving agent can unambiguously determine the charset used.
skipping to change at line 660 skipping to change at line 681
Content-Type: multipart/mixed; boundary=bar Content-Type: multipart/mixed; boundary=bar
--bar --bar
Content-Type: text/plain; charset=iso-8859-1 Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable
=A1Hola Michael! =A1Hola Michael!
How do you like the new S/MIME specification? How do you like the new S/MIME specification?
I agree. It's generally a good idea to encode lines that begin I agree. It's generally a good idea to encode lines that begin with
with
From=20because some mail transport agents will insert a greater- From=20because some mail transport agents will insert a greater-
than (>) sign, thus invalidating the signature. than (>) sign, thus invalidating the signature.
Also, in some cases it might be desirable to encode any =20 Also, in some cases it might be desirable to encode any =20
trailing whitespace that occurs on lines in order to ensure =20 trailing whitespace that occurs on lines in order to ensure =20
that the message signature is not invalidated when passing =20 that the message signature is not invalidated when passing =20
a gateway that modifies such whitespace (like BITNET). =20 a gateway that modifies such whitespace (like BITNET). =20
--bar --bar
Content-Type: image/jpeg Content-Type: image/jpeg
skipping to change at line 722 skipping to change at line 742
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, .p7m Application/pkcs7-mime (signedData, .p7m
envelopedData) envelopedData)
application/pkcs7-mime (degenerate .p7c Application/pkcs7-mime (degenerate .p7c
signedData "certs-only" message) signedData "certs-only" 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
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 751 skipping to change at line 771
application/octet-stream and treat it as a generic attachment, thus application/octet-stream and treat it as a generic attachment, thus
losing the type information. However, the suggested filename for an losing the type information. However, the suggested filename for an
attachment is often carried across a gateway. This often allows the attachment is often carried across a gateway. This often allows the
receiving systems to determine the appropriate application to hand the receiving systems to determine the appropriate application to hand the
attachment off to, in this case a stand-alone S/MIME processing attachment off to, in this case a stand-alone S/MIME processing
application. Note that this mechanism is provided as a convenience for application. Note that this mechanism is provided as a convenience for
implementations in certain environments. A proper S/MIME implementations in certain environments. A proper S/MIME
implementation MUST use the MIME types and MUST not rely on the file implementation MUST use the MIME types and MUST not rely on the file
extensions. extensions.
3.2.2 The smime-type parameter
The application/pkcs7-mime content type defines the optional "smime-
type" parameter. The intent of this parameter is to convey details
about the security applied (signed or enveloped) along with infomation
about the contained content. This draft defines the following smime-
types.
Name Security Inner Content
enveloped-data EnvelopedData id-data
signed-data SignedData id-data
certs-only SignedData none
In order that consistency can be obtained with future, the following
guidelines should be followed when assigning a new smime-type
parameter.
1. If both signing and encryption can be applied to the content, then
two values for smime-type SHOULD be assigned "signed-*" and "encrypted-
*". If one operation can be assigned then this may be omitted. Thus
since "certs-only" can only be signed, "signed-" is omitted.
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.
3. If no common string is assigned. Then the common string of
"OID.<oid>" is recommended.
3.3 Creating an Enveloped-only Message 3.3 Creating an Enveloped-only Message
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.
skipping to change at line 857 skipping to change at line 908
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 single CMS object of type signedData.
The signedData encapContentInfo eContent field MUST be absent. The The signedData encapContentInfo eContent field MUST be absent. The
signerInfos field contains the signatures for the MIME entity. The signerInfos field contains the signatures for the MIME entity.
details of the registered type are given in Appendix E.
The file extension for signed-only messages using application/pkcs7- The file extension for signed-only messages using application/pkcs7-
signature is ".p7s". signature is ".p7s".
3.4.3.2 Creating a multipart/signed Message 3.4.3.2 Creating a multipart/signed Message
Step 1. The MIME entity to be signed is prepared according to section Step 1. The MIME entity to be signed is prepared according to section
3.1, taking special care for clear-signing. 3.1, taking special care for clear-signing.
Step 2. The MIME entity is presented to CMS processing in order to Step 2. The MIME entity is presented to CMS processing in order to
skipping to change at line 1189 skipping to change at line 1239
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 5} {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 5}
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}
id-aa-encrypKeyPref OBJECT IDENTIFIER ::= id-aa-encrypKeyPref OBJECT IDENTIFIER ::=
{id-aa 11} {id-aa 11}
B. References B. References
[3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES," [3DES] ANSI X9.52-1998, "Triple Data Encryption Algorithm Modes of
IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41. Operation", American National Standards Institute, 1998.
[CERT3] "S/MIME Version 3 Certificate Handling", Internet Draft draft- [CERT3] "S/MIME Version 3 Certificate Handling", Internet Draft draft-
ietf-smime-cert-*.txt. ietf-smime-cert-*.txt.
[CHARSETS] Character sets assigned by IANA. See <ftp://ftp.isi.edu/in- [CHARSETS] Character sets assigned by IANA. See <ftp://ftp.isi.edu/in-
notes/iana/assignments/character-sets>. notes/iana/assignments/character-sets>.
[CMS] "Cryptographic Message Syntax", Internet Draft draft-ietf-smime- [CMS] "Cryptographic Message Syntax", Internet Draft draft-ietf-smime-
cms-*.txt. cms-*.txt.
[CONTDISP] "Communicating Presentation Information in Internet [CONTDISP] "Communicating Presentation Information in Internet
Messages: The Content-Disposition Header Field", RFC 2183 Messages: The Content-Disposition Header Field", RFC 2183
[DES] ANSI X3.106, "American National Standard for Information Systems- [DES] ANSI X3.106, "American National Standard for Information Systems-
Data Link Encryption," American National Standards Institute, 1983. Data Link Encryption," American National Standards Institute, 1983.
[DH] ANSI X9.42 TBD [DH] ANSI X9.42 TBD
[DSS] ANSI X9.57-199x, "Public Key Cryptography For The Financial [DSS] NIST FIPS PUB 186, "Digital Signature Standard", 18 May 1994.
Services Industry: Certificate Management" (Working Draft), 21 June,
1996.
[ESS] "Enhanced Security Services for S/MIME", Internet draft, draft- [ESS] "Enhanced Security Services for S/MIME", Internet draft, draft-
ietf-smime-ess-*.txt. ietf-smime-ess-*.txt.
[MD5] "The MD5 Message Digest Algorithm", RFC 1321 [MD5] "The MD5 Message Digest Algorithm", RFC 1321
[MIME-SPEC] The primary definition of MIME. "MIME Part 1: Format of [MIME-SPEC] The primary definition of MIME. "MIME Part 1: Format of
Internet Message Bodies", RFC 2045; "MIME Part 2: Media Types", RFC Internet Message Bodies", RFC 2045; "MIME Part 2: Media Types", RFC
2046; "MIME Part 3: Message Header Extensions for Non-ASCII Text", RFC 2046; "MIME Part 3: Message Header Extensions for Non-ASCII Text", RFC
2047; "MIME Part 4: Registration Procedures", RFC 2048; "MIME Part 5: 2047; "MIME Part 4: Registration Procedures", RFC 2048; "MIME Part 5:
skipping to change at line 1253 skipping to change at line 1301
This document is largely derived from [SMIMEV2] written by Steve This document is largely derived from [SMIMEV2] written by Steve
Dusse, Paul Hoffman, Blake Ramsdell, Laurence Lundblade, and Lisa Dusse, Paul Hoffman, Blake Ramsdell, Laurence Lundblade, and Lisa
Repka. Repka.
Significant comments and additions were made by John Pawling and Jim Significant comments and additions were made by John Pawling and Jim
Schaad. Schaad.
D. Changes from last draft D. Changes from last draft
SMIMECapabilities and SMIMEEncryptionKeyPreference clarified to be Changed section 2.5 to clarify signed attributes handling (Paul
only single-instance, signed attributes (John Pawling) Hoffman)
Removed keylength specifications for RSA signing and encryption (to be Changed [3DES] reference (Russ Housley)
moved to CMS section 12) (John Pawling) Clarified 3.1.1 regarding canonicalization by the sending agent vs.
Slight wording changes in section 3.1 (security layers being "removed" the S/MIME part (Bill Flanigan, Paul Hoffman)
changed to "processed") (Paul Hoffman and offline comments) Various small language changes (Bill Flanigan, Paul Hoffman)
Added data integrity risks for enveloped-only data in section 3.3 and Changed [DSS] reference to FIPS 186 (Bill Flanigan)
section 5 (Paul Hoffman and offline comments) Added section 3.2.2 for smime-type clarification (Jim Schaad)
Fixed a typo in CBCParameter (Paul Hoffman) Added definitions for "agents" (Bill Flanigan, Paul Hoffman)
Changed a reference to authenticated attributes to be signed Inserted section 2.6 for SignerIdentifier (WG consensus)
attributes (John Pawling)
Removed application/mime (Paul Hoffman)
F. Editor's address F. Editor's address
Blake Ramsdell Blake Ramsdell
Worldtalk Worldtalk
13122 NE 20th St., Suite C 13122 NE 20th St., Suite C
Bellevue, WA 98005 Bellevue, WA 98005
(425) 882-8861 (425) 882-8861
blaker@deming.com blaker@deming.com
 End of changes. 

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