draft-ietf-smime-rfc2633bis-02.txt   draft-ietf-smime-rfc2633bis-03.txt 
Internet Draft Editor: Blake Ramsdell, Internet Draft Editor: Blake Ramsdell,
draft-ietf-smime-rfc2633bis-02.txt Brute Squad Labs draft-ietf-smime-rfc2633bis-03.txt Brute Squad Labs
October 30, 2002 January 16, 2003
Expires April 30, 2003 Expires July 16, 2003
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 145 skipping to change at line 145
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 Changes Since S/MIME v3.0 1.5 Changes Since S/MIME v3.0
[TBD] The RSA public key algorithm was changed to a MUST implement key
wrapping algorithm, and the Diffie-Hellman algorithm changed to a
SHOULD implement.
The RSA public key algorithm was changed to a MUST implement signature
algorithm.
Ambiguous language about the use of "empty" SignedData messages to
transmit certificates was clarified to reflect that transmission of
certificate revocation lists is also allowed.
The use of binary encoding for some MIME entities is now explicitly
discussed.
Header protection through the use of the message/rfc822 MIME type has
been added.
Use of the CompressedData CMS type is allowed, along with required
MIME type and file extension additions.
1.6 Discussion of This Specification 1.6 Discussion of This Specification
This specification is being discussed on the "ietf-smime" mailing This specification is being discussed on the "ietf-smime" mailing
list. To subscribe, send a message to: list. To subscribe, send a message to:
ietf-smime-request@imc.org ietf-smime-request@imc.org
with the single word with the single word
skipping to change at line 1072 skipping to change at line 1090
rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
0GhIGfHfQbnj756YT64V 0GhIGfHfQbnj756YT64V
3.6 Multiple Operations 3.6 Multiple Operations
Any of the signed-only, compressed-only and encrypted-only MIME Any of the signed-only, compressed-only and encrypted-only MIME
formats listed above may be nested. This is allowed because the above formats listed above may be nested. This is allowed because the above
formats are all MIME entities, and because they all secure MIME formats are all MIME entities, and because they all encapsulate MIME
entities. 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 implementor 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,
skipping to change at line 1097 skipping to change at line 1115
There are security ramifications to choosing whether to sign first or There are security ramifications to choosing whether to sign first or
encrypt first. A recipient of a message that is encrypted and then encrypt first. A recipient of a message that is encrypted and then
signed can validate that the encrypted block was unaltered, but cannot signed can validate that the encrypted block was unaltered, but cannot
determine any relationship between the signer and the unencrypted determine any relationship between the signer and the unencrypted
contents of the message. A recipient of a message that is signed-then- contents of the message. A recipient of a message that is signed-then-
encrypted can assume that the signed message itself has not been encrypted can assume that the signed message itself has not been
altered, but that a careful attacker may have changed the altered, but that a careful attacker may have changed the
unauthenticated portions of the encrypted message. unauthenticated portions of the encrypted message.
When using compression, the only guidance we will give here is to not When using compression, keep the following guidelines in mind:
compress encrypted data, since this will not yield significant
compression. - Compression of binary encoded encrypted data is discouraged, since
it will not yield significant compression. Base64 encrypted data
could very well benefit, however.
- If a lossy compression algorithm is used with signing, you will need
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
skipping to change at line 1241 skipping to change at line 1263
strengths of cryptography, an attacker watching the communications strengths of cryptography, an attacker watching the communications
channel may be able to determine the contents of the strongly- channel may be able to determine the contents of the strongly-
encrypted message by decrypting the weakly-encrypted version. In other encrypted message by decrypting the weakly-encrypted version. In other
words, a sender should not send a copy of a message using weaker words, a sender should not send a copy of a message using weaker
cryptography than they would use for the original of the message. cryptography than they would use for the original of the message.
Modification of the ciphertext can go undetected if authentication is Modification of the ciphertext can go undetected if authentication is
not also used, which is the case when sending EnvelopedData without not also used, which is the case when sending EnvelopedData without
wrapping it in SignedData or enclosing SignedData within it. wrapping it in SignedData or enclosing SignedData within it.
[TBD] -- PKCS #1 v1.5 warnings (RFC 3218) See RFC 3218 [MMA] for more information about thwarting the adaptive
chosen ciphertext vulnerability in PKCS #1 Version 1.5
implementations.
[TBD] -- Small subgroup Diffie-Hellman (RFC 2785) In some circumstances the use of the Diffie-Hellman key agreement
scheme in a prime order subgroup of a large prime p is vulnerable to
certain attacks known as "small-subgroup" attacks. Methods exist,
however, to prevent these attacks. These methods are described in RFC
2785 [DHSUB].
A. ASN.1 Module A. ASN.1 Module
SecureMimeMessageV3 SecureMimeMessageV3dot1
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) smime(4) } pkcs(1) pkcs-9(9) smime(16) modules(0) msg-v3dot1(21) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
IMPORTS IMPORTS
-- Cryptographic Message Syntax -- Cryptographic Message Syntax
SubjectKeyIdentifier, IssuerAndSerialNumber, SubjectKeyIdentifier, IssuerAndSerialNumber,
RecipientKeyIdentifier RecipientKeyIdentifier
FROM CryptographicMessageSyntax FROM CryptographicMessageSyntax
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) }; pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) };
-- id-aa is the arc with all new authenticated and unauthenticated -- id-aa is the arc with all new authenticated and unauthenticated
-- attributes produced the by S/MIME Working Group -- attributes produced the by S/MIME Working Group
id-aa OBJECT IDENTIFIER ::= {iso(1) member-body(2) usa(840) id-aa OBJECT IDENTIFIER ::= {iso(1) member-body(2) usa(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) attributes(2)} rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) attributes(2)}
-- S/MIME Capabilities provides a method of broadcasting the symetric -- S/MIME Capabilities provides a method of broadcasting the symetric
-- capabilities understood. Algorithms should be ordered by -- capabilities understood. Algorithms should be ordered by
-- preference and grouped by type -- preference and grouped by type
skipping to change at line 1338 skipping to change at line 1366
[CMS] "Cryptographic Message Syntax", RFC 3369 [CMS] "Cryptographic Message Syntax", RFC 3369
[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
[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 [PKCS-7] "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315
[RANDOM] "Randomness Recommendations for Security", RFC 1750 [RANDOM] "Randomness Recommendations for Security", RFC 1750
[SMIMEV2] "S/MIME Version 2 Message Specification", RFC 2311 [SMIMEV2] "S/MIME Version 2 Message Specification", RFC 2311
C. Acknowledgements C. Acknowledgements
[tbd] Many thanks go out to the other authors of the S/MIME Version 2
Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence
Lundblade and Lisa Repka.
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
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
made direct contributions to this document.
Tony Capel
Piers Chivers
Dave Crocker
Bill Flanigan
Paul Hoffman
Russ Housley
William Ottaway
John Pawling
Jim Schaad
D. Editor's address D. Editor's address
Blake Ramsdell Blake Ramsdell
Brute Squad Labs Brute Squad Labs
Suite 217-C Suite 217-C
16451 Redmond Way 16451 Redmond Way
Redmond, WA 98052-4482 Redmond, WA 98052-4482
blake@brutesquadlabs.com blake@brutesquadlabs.com
E. Changes from last draft E. Changes from last draft
Reverted cert-management to certs-only for the MIME type, and removed English fixes (Jim Schaad)
related backward compatibility statements (Jim Schaad, Russ Housley)
Binary encoding changes (Tony Capel) Compression guidance (Jim Schaad)
Updated references to CMS, CMSALG and ESS to point to RFCs (Blake MMA language taken verbatim from [CMSALG] (Blake Ramsdell, Russ
Ramsdell) Housley)
Added message/rfc822 language to section 3.1 (Blake Ramsdell) Small subgroup Diffie Hellman taken verbatim from [DHSUB] (Blake
Ramsdell, R. Zuccherato)
Added compressed data language (new section 3.5, modifications to Module ID changes (Jim Schaad, Russ Housley)
section 3.6, new smime-type and file extension) (Blake Ramsdell)
Acknowlegements (Blake Ramsdell)
Changes since S/MIME v3 (Blake Ramsdell)
 End of changes. 

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