draft-ietf-smime-msg-00.txt   draft-ietf-smime-msg-01.txt 
Internet Draft Editor: Blake Ramsdell, Internet Draft Editor: Blake Ramsdell,
draft-ietf-smime-msg-00.txt Worldtalk draft-ietf-smime-msg-01.txt Worldtalk
November 20, 1997 January 28, 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 160 skipping to change at line 160
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. among all S/MIME implementations.
2.1 DigestAlgorithmIdentifier 2.1 DigestAlgorithmIdentifier
Receiving agents MUST support SHA-1 [SHA1] and MD5 [MD5]. Receiving agents MUST support SHA-1 [SHA1]. Receiving agents SHOULD
support MD5 [MD5] for the purpose of providing backward compatibility
with MD5-digested S/MIME v2 SignedData objects.
Sending agents SHOULD use SHA-1. Sending agents SHOULD use SHA-1.
2.2 DigestEncryptionAlgorithmIdentifier 2.2 DigestEncryptionAlgorithmIdentifier
Sending and receiving agents MUST support id-dsa defined in [DSS]. Sending and receiving agents MUST support id-dsa defined in [DSS].
The algorithm parameters MUST be absent (not encoded as NULL). The algorithm parameters MUST be absent (not encoded as NULL).
Receiving agents SHOULD support rsaEncryption, defined in [PKCS-1]. Receiving agents SHOULD support rsaEncryption, defined in [PKCS-1].
Receiving agents SHOULD support verification of signatures using RSA Receiving agents SHOULD support verification of signatures using RSA
skipping to change at line 193 skipping to change at line 195
messages contain symmetric keys which are to be decrypted with a messages contain symmetric keys which are to be decrypted with a
user's private key. The size of the private key is determined during user's private key. The size of the private key is determined during
key generation. key generation.
Sending agents SHOULD support rsaEncryption. Sending agents MUST Sending agents SHOULD support rsaEncryption. Sending agents MUST
support encryption of symmetric keys with RSA public keys at key sizes support encryption of symmetric keys with RSA public keys at key sizes
from 512 bits to 1024 bits. from 512 bits to 1024 bits.
2.4 General Syntax 2.4 General Syntax
CMS defines three distinct content types: "data", "signedData", and CMS defines multiple content types. Of these, only the Data,
"envelopedData". SignedData, and EnvelopedData content types are currently used for
S/MIME.
2.4.1 Data Content Type 2.4.1 Data Content Type
ending agents MUST use the "data" content type as the content within Sending agents MUST use the "data" content type as the content within
other content types to indicate the message content which has had other content types to indicate the message content which has had
security services applied to it. security services applied to it.
2.4.2 SignedData Content Type 2.4.2 SignedData Content Type
Sending agents MUST use the signedData content type to apply a digital Sending agents MUST use the signedData content type to apply a digital
signature to a message or, in a degenerate case where there is no signature to a message or, in a degenerate case where there is no
signature information, to convey certificates. signature information, to convey certificates.
2.4.3 EnvelopedData Content Type 2.4.3 EnvelopedData Content Type
skipping to change at line 302 skipping to change at line 305
The registered SMIMECapabilities list specifies the parameters for The registered SMIMECapabilities list specifies the parameters for
OIDs that need them, most notably key lengths in the case of variable- OIDs that need them, most notably key lengths in the case of variable-
length symmetric ciphers. In the event that there are no length symmetric ciphers. In the event that there are no
differentiating parameters for a particular OID, the parameters MUST differentiating parameters for a particular OID, the parameters MUST
be omitted, and MUST NOT be encoded as NULL. be omitted, and MUST NOT be encoded as NULL.
Additional values for the SMIMECapabilities attribute may be defined Additional values for the SMIMECapabilities attribute may be defined
in the future. Receiving agents MUST handle a SMIMECapabilities object in the future. Receiving agents MUST handle a SMIMECapabilities object
that has values that it does not recognize in a graceful manner. that has values that it does not recognize in a graceful manner.
2.5.3 Encryption Key Preference Attribute
The encryption key preference attribute allows for the signer to
unambiguously describe which of the certificates issued to the signer
should be used when sending encrypted content. This attribute allows
for the signer to state a preference, but not a requirement, as to the
certificate to be used. This attribute is designed to enhance
behavior for interoperating with those clients which use separate keys
for encryption and signing. This attribute is used to convey to the
receiver which of the certificates should be used for encrypting the
session key.
The sending agent SHOULD include the referenced certificate in the set
of certificates included in the signed message if this attribute is
used. The certificate may be omitted if it has been previously made
available to the receiving agent. Sending agents SHOULD use this
attribute if the commonly used or preferred encryption certificate is
not the same as the certificate used to sign the message.
Receiving agents SHOULD store the preference data if the signature on
the message is valid and the signing time is greater than the
currently stored value. (As with the SMIMECapabilities, the clock
skew should be checked and the data not used if the skew is to great.)
Receiving agents SHOULD respect the senders encryption key preference
attribute if possible. This however represents only a preference and
the receiving agent may use any certificate in replying to the sender
that is valid.
2.6 ContentEncryptionAlgorithmIdentifier 2.6 ContentEncryptionAlgorithmIdentifier
Receiving agents MUST support encryption and decryption with DES EDE3 Receiving agents MUST support encryption and decryption with DES EDE3
CBC, hereinafter called "tripleDES" [3DES] [DES]. Receiving agents CBC, hereinafter called "tripleDES" [3DES] [DES]. Receiving agents
SHOULD support encryption and decryption using the RC2 [RC2] or a SHOULD support encryption and decryption using the RC2 [RC2] or a
compatible algorithm at a key size of 40 bits, hereinafter called compatible algorithm at a key size of 40 bits, hereinafter called
"RC2/40". "RC2/40".
2.6.1 Multiple Recipients 2.6.1 Deciding Which Encryption Method To Use
When a sending agent creates an encrypted message, it has to decide
which type of encryption to use. The decision process involves using
information garnered from the capabilities lists included in messages
received from the recipient, as well as out-of-band information such
as private agreements, user preferences, legal restrictions, and so
on.
Section 2.5 defines a method by which a sending agent can optionally
announce, among other things, its decrypting capabilities in its order
of preference. The following method for processing and remembering the
encryption capabilities attribute in incoming signed messages SHOULD
be used.
- If the receiving agent has not yet created a list of capabilities
for the sender's public key, then, after verifying the signature
on the incoming message and checking the timestamp, the receiving
agent SHOULD create a new list containing at least the signing
time and the symmetric capabilities.
- If such a list already exists, the receiving agent SHOULD verify
that the signing time in the incoming message is greater than
the signing time stored in the list and that the signature is
valid. If so, the receiving agent SHOULD update both the signing
time and capabilities in the list. Values of the signing time that
lie far in the future (that is, a greater discrepancy than any
reasonable clock skew), or a capabilitie lists in messages whose
signature could not be verified, MUST NOT be accepted.
The list of capabilities SHOULD be stored for future use in creating
messages.
Before sending a message, the sending agent MUST decide whether it is
willing to use weak encryption for the particular data in the message.
If the sending agent decides that weak encryption is unacceptable for
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
any other decision in this section about which encryption algorithm to
use.
Sections 2.6.2.1 through 2.6.2.4 describe the decisions a sending
agent SHOULD use in deciding which type of encryption should be
applied to a message. These rules are ordered, so the sending agent
SHOULD make its decision in the order given.
2.6.2.1 Rule 1: Known Capabilities
If the sending agent has received a set of capabilities from the
recipient for the message the agent is about to encrypt, then the
sending agent SHOULD use that information by selecting the first
capability in the list (that is, the capability most preferred by the
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 agent reasonably expects the recipient to be able to decrypt the
message.
2.6.2.2 Rule 2: Unknown Capabilities, Known Use of Encryption
If:
- the sending agent has no knowledge of the encryption capabilities
of the recipient,
- and the sending agent has received at least one message from the
recipient,
- and the last encrypted message received from the recipient had a
trusted signature on it,
then the outgoing message SHOULD use the same encryption algorithm as
was used on the last signed and encrypted message received from the
recipient.
2.6.2.3 Rule 3: Unknown Capabilities, Risk of Failed Decryption
If:
- the sending agent has no knowledge of the encryption capabilities
of the recipient,
- and the sending agent is willing to risk that the recipient may
not be able to decrypt the message,
then the sending agent SHOULD use tripleDES.
2.6.2.4 Rule 4: Unknown Capabilities, No Risk of Failed Decryption
If:
- the sending agent has no knowledge of the encryption capabilities
of the recipient,
- and the sending agent is not willing to risk that the recipient
may not be able to decrypt the message,
then the sending agent MUST use RC2/40.
2.6.3 Choosing Weak Encryption
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
SHOULD allow a human sender to determine the risks of sending data
using RC2/40 or a similarly weak encryption algorithm before sending
the data, and possibly allow the human to use a stronger encryption
method such as tripleDES.
2.6.4 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 987 skipping to change at line 1114
A. Object Identifiers and Syntax A. Object Identifiers and Syntax
The syntax for SMIMECapability is: The syntax for SMIMECapability is:
SMIMECapability ::= SEQUENCE { SMIMECapability ::= SEQUENCE {
capabilityID OBJECT IDENTIFIER, capabilityID OBJECT IDENTIFIER,
parameters OPTIONAL ANY DEFINED BY capabilityID } parameters OPTIONAL ANY DEFINED BY capabilityID }
SMIMECapabilities ::= SEQUENCE OF SMIMECapability SMIMECapabilities ::= SEQUENCE OF SMIMECapability
The syntax for SMIMEEncryptionKeyPreference is:
SMIMEEncryptionKeyPreference ::= CHOICE {
issuerAndSerialNumber [0] IssuerAndSerialNumber,
receipentKeyId [1] RecipientKeyIdentifier,
subjectAltKeyIdentifier [2] KeyIdentifier
}
A.1 Content Encryption Algorithms A.1 Content Encryption Algorithms
RC2-CBC OBJECT IDENTIFIER ::= RC2-CBC OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) {iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3)
2} 2}
For the effective-key-bits (key size) greater than 32 and less than For the effective-key-bits (key size) greater than 32 and less than
256, the RC2-CBC algorithm parameters are encoded as: 256, the RC2-CBC algorithm parameters are encoded as:
RC2-CBC parameter ::= SEQUENCE { RC2-CBC parameter ::= SEQUENCE {
rc2ParameterVersion INTEGER, rc2ParameterVersion INTEGER,
iv OCTET STRING (8)} iv OCTET STRING (8)}
For the effective-key-bits of 40, 64, and 128, the rc2ParameterVersion For the effective-key-bits of 40, 64, and 128, the rc2ParameterVersion
values are 160, 120, 58 respectively. values are 160, 120, 58 respectively.
DES-EDE3-CBC OBJECT IDENTIFIER ::= DES-EDE3-CBC OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) {iso(1) member-body(2) us(840) rsadsi(113549)
7} encryptionAlgorithm(3) 7}
For DES-CBC and DES-EDE3-CBC, the parameter should be encoded as: For DES-CBC and DES-EDE3-CBC, the parameter should be encoded as:
CBCParameter :: IV CBCParameter :: IV
where IV ::= OCTET STRING -- 8 octets. where IV ::= OCTET STRING -- 8 octets.
A.2 Digest Algorithms A.2 Digest Algorithms
md5 OBJECT IDENTIFIER ::= md5 OBJECT IDENTIFIER ::=
skipping to change at line 1074 skipping to change at line 1209
[CMS] "Cryptographic Message Syntax", Internet Draft draft-housley- [CMS] "Cryptographic Message Syntax", Internet Draft draft-housley-
smime-cms smime-cms
[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 X.42 TBD [DH] ANSI X9.42 TBD
[DSS] ANSI X9.57-199x, "Public Key Cryptography For The Financial [DSS] ANSI X9.57-199x, "Public Key Cryptography For The Financial
Services Industry: Certificate Management" (Working Draft), 21 June, Services Industry: Certificate Management" (Working Draft), 21 June,
1996. 1996.
[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
skipping to change at line 1175 skipping to change at line 1310
The RC2 symmetric encryption algorithm has been approved by the US The RC2 symmetric encryption algorithm has been approved by the US
Government for "expedited" export licensing at certain key sizes. Government for "expedited" export licensing at certain key sizes.
Consequently, support for the RC2 algorithm in CBC mode is required Consequently, support for the RC2 algorithm in CBC mode is required
for baseline interoperability in all S/MIME implementations. Support for baseline interoperability in all S/MIME implementations. Support
for other strong symmetric encryption algorithms such as RC5 CBC, DES for other strong symmetric encryption algorithms such as RC5 CBC, DES
CBC and DES EDE3-CBC for content encryption is strongly encouraged CBC and DES EDE3-CBC for content encryption is strongly encouraged
where possible. where possible.
D. Changes from S/MIME v2 D. Changes from S/MIME v2
Changed Section 2.1 to SHOULD instead of MUST support MD5.
Changed Section 2.2 to MUST support DSS for receiving and sending and Changed Section 2.2 to MUST support DSS for receiving and sending and
SHOULD support RSA for receiving and sending. SHOULD support RSA for receiving and sending.
Changed Section 2.3 to MUST support Diffie-Hellman for receiving and Changed Section 2.3 to MUST support Diffie-Hellman for receiving and
sending and SHOULD support RSA for receiving and sending. sending and SHOULD support RSA for receiving and sending.
Changed Section 2.6 to MUST support tripleDES for receiving and Changed Section 2.6 to MUST support tripleDES for receiving and
sending and SHOULD support RC2/40 for receiving and sending. sending and SHOULD support RC2/40 for receiving and sending.
Yanked 2.6.1 - 2.6.3 regarding 40-bit issues.
Changed some references from [PKCS-7] to [CMS] and added [CMS]. Changed some references from [PKCS-7] to [CMS] and added [CMS].
Added Section 2.5.3, SMIMEEncryptionKeyPreference.
E. Request for New MIME Subtypes E. Request for New MIME Subtypes
E.1 application/pkcs7-mime E.1 application/pkcs7-mime
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkcs7-mime Subject: Registration of MIME media type application/pkcs7-mime
MIME media type name: application MIME media type name: application
MIME subtype name: pkcs7-mime MIME subtype name: pkcs7-mime
skipping to change at line 1488 skipping to change at line 1625
the filename for the attachment. If the intervening gateway has the filename for the attachment. If the intervening gateway has
carried the file type, it will end in ".aps" and be recognized as an carried the file type, it will end in ".aps" and be recognized as an
S/MIME message. S/MIME message.
G. Acknowledgements G. Acknowledgements
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
Schaad.
H. Needed changes H. Needed changes
Section 2.5.2 Add certs as an authenticatedAttribute
[DH] is undefined in section 2.3
Need OIDs for Diffie-Hellman Need OIDs for Diffie-Hellman
What do we need to do for 4.1 in order to make it Diffie-Hellman? What do we need to do for 4.1 in order to make it Diffie-Hellman?
Do we need to put back 2.6.1-2.6.3?
Cert generation in section 4.1 needs to talk about CMP from PKIX. Cert generation in section 4.1 needs to talk about CMP from PKIX.
Perhaps another draft? Perhaps another draft?
Section 4.1 needs to talk about DSS and DH minimum key lengths for Section 4.1 needs to talk about DSS and DH minimum key lengths for
strong crypto strong crypto
Is [DSS] the correct reference? Is [DSS] the correct reference?
Is id-dsa the correct OID to use for Algorithm identifiers need more cleanup
DigestEncryptionAlgorithmIdentifier? Section A cleanup (SMIMECapabilities and SMIMEEncryptionKeyPreference
Is section 4.1 worded correctly? in their own sections?)
Should SMIMEEncryptionKeyPreference simply be IssuerAndSerialNumber?
ASN.1 issues -- syntax, CCITT vs. ITU-T in section 1.3
I. Changes from last draft I. Changes from last draft
Added section I (Changes from last draft) Changed language in 2.1 to SHOULD instead of MUST support MD5
Changed [DH-DSS] to [DSS] Added some acknowledgements
Added [DSS] reference Put back section 2.6.1-2.6.3, text from S/MIME v2
Added OID for id-dsa Fixed various typos
Redid 4.1 with changes for separate DSS and DH keypairs and optional Added section 2.5.3 for encryption key preference, text from Jim
RSA support Schaad
Added part of [DH] reference Added SMIMEEncryptionKeyPreference to section A, text from Jim Schaad
Changed the sMIMECapabilities OID to smimeCapabilities Changed 2.4 to reflect subset of supported content types from [CMS]
Added id-dsa-with-sha1 Updated section D
J. Editor's address J. 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/