draft-ietf-smime-rfc2633bis-06.txt   draft-ietf-smime-rfc2633bis-07.txt 
Internet Draft Editor: Blake Ramsdell, Internet Draft Editor: Blake Ramsdell,
draft-ietf-smime-rfc2633bis-06.txt Brute Squad Labs draft-ietf-smime-rfc2633bis-07.txt Sendmail, Inc.
October 26, 2003 February 15, 2004
Expires April 26, 2004 Expires August 15, 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 394 skipping to change at line 394
length symmetric ciphers. In the event that there are no length symmetric ciphers. In the event that there are no
differentiating parameters for a particular OID, the parameters MUST differentiating parameters for a particular OID, the parameters MUST
be omitted, and MUST NOT be encoded as NULL. be omitted, and MUST NOT be encoded as NULL.
Additional values for the SMIMECapabilities attribute may be defined Additional values for the SMIMECapabilities attribute may be defined
in the future. Receiving agents MUST handle a SMIMECapabilities object in the future. Receiving agents MUST handle a SMIMECapabilities object
that has values that it does not recognize in a graceful manner. that has values that it does not recognize in a graceful manner.
Section 2.7.1 explains a strategy for caching capabilities. Section 2.7.1 explains a strategy for caching capabilities.
2.5.2.1 SMIMECapability For the RC2 Algorithm
For the RC2 algorithm preference SMIMECapability, the capabilityID
MUST be set to the value rC2-CBC as defined in [CMSALG]. The
parameters field MUST contain SMIMECapabilitiesParametersForRC2CBC
(see appendix A).
Please note that the SMIMECapabilitiesParametersForRC2CBC is a single
INTEGER which contains the effective key length (NOT the corresponding
RC2 parameter version value). So, for example, for RC2 with a 128-bit
effective key length, the parameter would be encoded as the INTEGER
value 128, NOT the corresponding parameter version of 58.
2.5.3 Encryption Key Preference Attribute 2.5.3 Encryption Key Preference Attribute
The encryption key preference attribute allows the signer to The encryption key preference attribute allows the signer to
unambiguously describe which of the signer's certificates has the unambiguously describe which of the signer's certificates has the
signer's preferred encryption key. This attribute is designed to signer's preferred encryption key. This attribute is designed to
enhance behavior for interoperating with those clients which use enhance behavior for interoperating with those clients which use
separate keys for encryption and signing. This attribute is used to separate keys for encryption and signing. This attribute is used to
convey to anyone viewing the attribute which of the listed convey to anyone viewing the attribute which of the listed
certificates should be used for encrypting a session key for future certificates should be used for encrypting a session key for future
encrypted messages. encrypted messages.
skipping to change at line 468 skipping to change at line 481
S/MIME v3.1 and S/MIME v3 requires the use of SignerInfo version 1, S/MIME v3.1 and S/MIME v3 requires the use of SignerInfo version 1,
that is the issuerAndSerialNumber CHOICE MUST be used for that is the issuerAndSerialNumber CHOICE MUST be used for
SignerIdentifier. SignerIdentifier.
S/MIME v3.1 implementations MUST allow for the use of the choice of S/MIME v3.1 implementations MUST allow for the use of the choice of
subjectKeyIdentifier in messages. Messages that use this choice cannot subjectKeyIdentifier in messages. Messages that use this choice cannot
be read by S/MIME v2 clients, and MUST be handled gracefully in S/MIME be read by S/MIME v2 clients, and MUST be handled gracefully in S/MIME
v3.1 clients. v3.1 clients.
It is important to understand that some certificates use a value for
subjectKeyIdentifier that is not suitable for uniquely identifying a
certificate. Implementations MUST be prepared for multiple
certificates for potentially different entities to have the same value
for subjectKeyIdentifier, and MUST be prepared to try each matching
certificate during signature verification before indicating an error
condition.
2.7 ContentEncryptionAlgorithmIdentifier 2.7 ContentEncryptionAlgorithmIdentifier
Sending and receiving agents MUST support encryption and decryption Sending and receiving agents MUST support encryption and decryption
with DES EDE3 CBC, hereinafter called "tripleDES" [CMSALG]. Receiving with DES EDE3 CBC, hereinafter called "tripleDES" [CMSALG]. Receiving
agents SHOULD support encryption and decryption using the RC2 [CMSALG] agents SHOULD support encryption and decryption using the RC2 [CMSALG]
or a compatible algorithm at a key size of 40 bits, hereinafter called or a compatible algorithm at a key size of 40 bits, hereinafter called
"RC2/40". Sending and receiving agents SHOULD support encryption and "RC2/40". Sending and receiving agents SHOULD support encryption and
decryption with AES [CMSAES] at a key size of 128, 192 and 256 bits. decryption with AES [CMSAES] at a key size of 128, 192 and 256 bits.
2.7.1 Deciding Which Encryption Method To Use 2.7.1 Deciding Which Encryption Method To Use
skipping to change at line 896 skipping to change at line 917
omitted. Thus since "certs-only" can only be signed, "signed-" is omitted. Thus since "certs-only" can only be signed, "signed-" is
omitted. omitted.
2. A common string for a content oid should be assigned. We use "data" 2. A common string for a content oid should be assigned. We use "data"
for the id-data content OID when MIME is the inner content. for the id-data content OID when MIME is the inner content.
3. If no common string is assigned. Then the common string of 3. If no common string is assigned. Then the common string of
"OID.<oid>" is recommended (for example, "OID.1.3.6.1.5.5.7.6.1" would "OID.<oid>" is recommended (for example, "OID.1.3.6.1.5.5.7.6.1" would
be DES40). be DES40).
It is explicitly intended that this field be a suitable hint for mail
client applications to indicate whether a message is "signed" or
"encrypted" without having to tunnel into the CMS payload.
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 1386 skipping to change at line 1411
-- 2} -- 2}
-- --
-- Other Signed Attributes -- Other Signed Attributes
-- --
-- signingTime OBJECT IDENTIFIER ::= -- signingTime OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) -- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
-- 5} -- 5}
-- See [CMS] for a description of how to encode the attribute -- See [CMS] for a description of how to encode the attribute
-- value. -- value.
SMIMECapabilitiesParametersForRC2CBC ::= INTEGER
-- (RC2 Key Length (number of bits))
END END
B. References B. Normative References
[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 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
[DHSUB] "Methods for Avoiding the "Small-Subgroup" Attacks on the
Diffie-Hellman Key Agreement Method for S/MIME", RFC 2785
[ESS] "Enhanced Security Services for S/MIME", RFC 2634 [ESS] "Enhanced Security Services for S/MIME", RFC 2634
[FIPS180-2] "Secure Hash Signature Standard (SHS)", National Institute [FIPS180-2] "Secure Hash Signature Standard (SHS)", National Institute
of Standards and Technology (NIST). FIPS Publication 180-2 of Standards and Technology (NIST). FIPS Publication 180-2
[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:
Conformance Criteria and Examples", RFC 2049 Conformance Criteria and Examples", RFC 2049
[MIME-SECURE] "Security Multiparts for MIME: Multipart/Signed and [MIME-SECURE] "Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847 Multipart/Encrypted", RFC 1847
[MMA] "Preventing the Million Message Attack on CMS", RFC 3218
[MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119 Levels", RFC 2119
[PKCS-7] "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315
[RANDOM] "Randomness Recommendations for Security", RFC 1750
[SMIMEV2] "S/MIME Version 2 Message Specification", RFC 2311
[X.208-88] CCITT. Recommendation X.208: Specification of Abstract [X.208-88] CCITT. Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1). 1988. Syntax Notation One (ASN.1). 1988.
[X.209-88] CCITT. Recommendation X.209: Specification of Basic [X.209-88] CCITT. Recommendation X.209: Specification of Basic
Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988. Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988.
[X.509-88] CCITT. Recommendation X.509: The Directory - Authentication [X.509-88] CCITT. Recommendation X.509: The Directory - Authentication
Framework. 1988. Framework. 1988.
C. Acknowledgements C. Informative References
[DHSUB] "Methods for Avoiding the "Small-Subgroup" Attacks on the
Diffie-Hellman Key Agreement Method for S/MIME", RFC 2785
[MMA] "Preventing the Million Message Attack on CMS", RFC 3218
[PKCS-7] "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315
[RANDOM] "Randomness Recommendations for Security", RFC 1750
[SMIMEV2] "S/MIME Version 2 Message Specification", RFC 2311
D. Acknowledgements
Many thanks go out to the other authors of the S/MIME Version 2 Many thanks go out to the other authors of the S/MIME Version 2
Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence
Lundblade and Lisa Repka. Lundblade and Lisa Repka.
A number of the members of the S/MIME Working Group have also worked A number of the members of the S/MIME Working Group have also worked
very hard and contributed to this document. Any list of people is very hard and contributed to this document. Any list of people is
doomed to omission, and for that I apologize. In alphabetical order, doomed to omission, and for that I apologize. In alphabetical order,
the following people stand out in my mind due to the fact that they the following people stand out in my mind due to the fact that they
made direct contributions to this document. made direct contributions to this document.
Tony Capel Tony Capel
Piers Chivers Piers Chivers
Dave Crocker Dave Crocker
Bill Flanigan Bill Flanigan
Peter Gutmann
Paul Hoffman Paul Hoffman
Russ Housley Russ Housley
William Ottaway William Ottaway
John Pawling John Pawling
Jim Schaad Jim Schaad
D. Editor's address E. Editor's address
Blake Ramsdell Blake Ramsdell
Brute Squad Labs Sendmail, Inc.
Suite 407-C 704 228th Ave NE #775
16451 Redmond Way Sammamish, WA 98074
Redmond, WA 98052-4482
blake@brutesquadlabs.com blake@sendmail.com
E. Changes from last draft F. Changes from last draft
Numerous changes (Jim Schaad) 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/