draft-ietf-smime-rfc3369bis-03.txt   draft-ietf-smime-rfc3369bis-04.txt 
S/MIME Working Group R. Housley S/MIME Working Group R. Housley
Internet-Draft Vigil Security Internet-Draft Vigil Security
When Approved, Obsoletes: 3369 April 2004 When Approved, Obsoletes: 3369 May 2004
Cryptographic Message Syntax (CMS) Cryptographic Message Syntax (CMS)
<draft-ietf-smime-rfc3369bis-03.txt> <draft-ietf-smime-rfc3369bis-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. 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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 2, line 8 skipping to change at page 2, line 8
Abstract Abstract
This document describes the Cryptographic Message Syntax (CMS). This This document describes the Cryptographic Message Syntax (CMS). This
syntax is used to digitally sign, digest, authenticate, or encrypt syntax is used to digitally sign, digest, authenticate, or encrypt
arbitrary message content. arbitrary message content.
Table of Contents Table of Contents
1 Introduction ............................................. ?? 1 Introduction ............................................. ??
1.1 Changes Since RFC 2630 ................................... ?? 1.1 Evolution of the CMS ..................................... ??
1.2 Changes Since RFC 3369 ................................... ?? 1.1.1 Changes Since PKCS #7 Version 1.5 ........................ ??
1.3 Terminology .............................................. ?? 1.1.2 Changes Since RFC 2630 ................................... ??
1.1.3 Changes Since RFC 3369 ................................... ??
1.2 Terminology .............................................. ??
1.3 Version Numbers .......................................... ??
2 General Overview ......................................... ?? 2 General Overview ......................................... ??
3 General Syntax ........................................... ?? 3 General Syntax ........................................... ??
4 Data Content Type ........................................ ?? 4 Data Content Type ........................................ ??
5 Signed-data Content Type ................................. ?? 5 Signed-data Content Type ................................. ??
5.1 SignedData Type .......................................... ?? 5.1 SignedData Type .......................................... ??
5.2 EncapsulatedContentInfo Type ............................. ?? 5.2 EncapsulatedContentInfo Type ............................. ??
5.2.1 Compatibility with PKCS #7 ............................... ?? 5.2.1 Compatibility with PKCS #7 ............................... ??
5.3 SignerInfo Type .......................................... ?? 5.3 SignerInfo Type .......................................... ??
5.4 Message Digest Calculation Process ....................... ?? 5.4 Message Digest Calculation Process ....................... ??
5.5 Signature Generation Process ............................. ?? 5.5 Signature Generation Process ............................. ??
skipping to change at page 4, line 32 skipping to change at page 4, line 32
[PROFILE]. [PROFILE].
The CMS values are generated using ASN.1 [X.208-88], using BER- The CMS values are generated using ASN.1 [X.208-88], using BER-
encoding [X.209-88]. Values are typically represented as octet encoding [X.209-88]. Values are typically represented as octet
strings. While many systems are capable of transmitting arbitrary strings. While many systems are capable of transmitting arbitrary
octet strings reliably, it is well known that many electronic mail octet strings reliably, it is well known that many electronic mail
systems are not. This document does not address mechanisms for systems are not. This document does not address mechanisms for
encoding octet strings for reliable transmission in such encoding octet strings for reliable transmission in such
environments. environments.
The CMS is derived from PKCS #7 version 1.5 as specified in RFC 2315 1.1 Evolution of the CMS
[PKCS#7]. Wherever possible, backward compatibility is preserved;
however, changes were necessary to accommodate version 1 attribute
certificate transfer, key agreement and symmetric key-encryption key
techniques for key management.
1.1 Changes Since RFC 2630 The CMS is derived from PKCS #7 version 1.5, which is documented in
RFC 2315 [PKCS#7]. PKCS #7 version 1.5 was developed outside of the
IETF; it was originally published as an RSA Laboratories Technical
Note in November 1993. Since that time, the IETF has taken
responsibility for the development and maintenance of the CMS.
Today, several important IETF standards-track protocols make use of
the CMS.
This section describes that changes that the IETF has made to the CMS
in each of the published versions.
1.1.1 Changes Since PKCS #7 Version 1.5
RFC 2630 [CMS1] was the first version of the CMS on the IETF
standards track. Wherever possible, backward compatibility with PKCS
#7 version 1.5 is preserved; however, changes were made to
accommodate version 1 attribute certificate transfer and to support
algorithm independent key management. PKCS #7 version 1.5 included
support only for key transport. RFC 2630 adds support for key
agreement and previously distributed symmetric key-encryption key
techniques.
1.1.2 Changes Since RFC 2630
RFC 3369 [CMS2] obsoletes RFC 2630 [CMS1] and RFC 3211 [PWRI]. RFC 3369 [CMS2] obsoletes RFC 2630 [CMS1] and RFC 3211 [PWRI].
Password-based key management is included in the CMS specification, Password-based key management is included in the CMS specification,
and an extension mechanism to support new key management schemes and an extension mechanism to support new key management schemes
without further changes to the CMS is specified. Backward without further changes to the CMS is specified. Backward
compatibility with RFC 2630 and RFC 3211 is preserved; however, compatibility with RFC 2630 and RFC 3211 is preserved; however,
version 2 attribute certificate transfer is added. The use of version 2 attribute certificate transfer is added, and the use of
version 1 attribute certificates is deprecated. version 1 attribute certificates is deprecated.
S/MIME v2 signatures [OLDMSG], which are based on PKCS#7 version 1.5, S/MIME v2 signatures [OLDMSG], which are based on PKCS#7 version 1.5,
are compatible with S/MIME v3 signatures [MSG], which are based on are compatible with S/MIME v3 signatures [MSG], which are based on
RFC 2630. However, there are some subtle compatibility issues with RFC 2630. However, there are some subtle compatibility issues with
signatures using PKCS#7 version 1.5 and the CMS. These issues are signatures based on PKCS #7 version 1.5. These issues are discussed
discussed in section 5.2.1. in section 5.2.1. These issues remain with the current version of
the CMS.
Specific cryptographic algorithms are not discussed in this document, Specific cryptographic algorithms are not discussed in this document,
but they were discussed in RFC 2630. The discussion of specific but they were discussed in RFC 2630. The discussion of specific
cryptographic algorithms has been moved to a separate document cryptographic algorithms has been moved to a separate document
[CMSALG]. Separation of the protocol and algorithm specifications [CMSALG]. Separation of the protocol and algorithm specifications
allows the IETF to update each document independently. This allows the IETF to update each document independently. This
specification does not require the implementation of any particular specification does not require the implementation of any particular
algorithms. Rather, protocols that rely on the CMS are expected to algorithms. Rather, protocols that rely on the CMS are expected to
choose appropriate algorithms for their environment. The algorithms choose appropriate algorithms for their environment. The algorithms
may be selected from [CMSALG] or elsewhere. may be selected from [CMSALG] or elsewhere.
1.2 Changes Since RFC 3369 1.1.3 Changes Since RFC 3369
This document obsoletes RFC 3369 [CMS2]. As discussed in the This document obsoletes RFC 3369 [CMS2]. As discussed in the
previous section, RFC 3369 introduced an extension mechanism to previous section, RFC 3369 introduced an extension mechanism to
support new key management schemes without further changes to the support new key management schemes without further changes to the
CMS. This document introduces a similar extension mechanism to CMS. This document introduces a similar extension mechanism to
support additional certificate formats and revocation status support additional certificate formats and revocation status
information formats without further changes to the CMS. These information formats without further changes to the CMS. These
extensions are primarily documented in section 10.2.1 and section extensions are primarily documented in section 10.2.1 and section
10.2.2. Backward compatibility with both RFC 2630 and RFC 3369 is 10.2.2. Backward compatibility with earlier versions of the CMS is
preserved. preserved.
The use of version numbers is described in section 1.3.
Since the publication of RFC 3369, a few errata have been noted. Since the publication of RFC 3369, a few errata have been noted.
These errata are posted on the RFC Editor web site. These errors These errata are posted on the RFC Editor web site. These errors
have been corrected in this document. have been corrected in this document.
The text in section 11.4 that describes the counter signature The text in section 11.4 that describes the counter signature
unsigned attribute is clarified. Hopefully the revised text is unsigned attribute is clarified. Hopefully the revised text is
clearer about the portion of the SignerInfo signature that is covered clearer about the portion of the SignerInfo signature that is covered
by a countersignature. by a countersignature.
1.3 Terminology 1.2 Terminology
In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as
described in [STDWORDS]. described in [STDWORDS].
1.3 Version Numbers
Each of the major data structures includes a version number as the
first item in the data structure. The version numbers are intended
to avoid ASN.1 decode errors. Some implementations do not check the
version number prior to attempting a decode, and if a decode error
occurs, then the version number is checked as part of the error
handling routine. This is a reasonable approach; it places error
processing outside of the fast path. This approach is also forgiving
when an incorrect version number is used by the sender.
Most of the initial version numbers were assigned in PKCS #7 version
1.5. Others were assigned when the structure was initially created.
Whenever a structure is updated, a higher version number is assigned.
However, to ensure maximum interoperability the higher version number
is only used when the new syntax feature is employed. That is, the
lowest version number that supports the generated syntax is used.
2 General Overview 2 General Overview
The CMS is general enough to support many different content types. The CMS is general enough to support many different content types.
This document defines one protection content, ContentInfo. This document defines one protection content, ContentInfo.
ContentInfo encapsulates a single identified content type, and the ContentInfo encapsulates a single identified content type, and the
identified type may provide further encapsulation. This document identified type may provide further encapsulation. This document
defines six content types: data, signed-data, enveloped-data, defines six content types: data, signed-data, enveloped-data,
digested-data, encrypted-data, and authenticated-data. Additional digested-data, encrypted-data, and authenticated-data. Additional
content types can be defined outside this document. content types can be defined outside this document.
skipping to change at page 9, line 40 skipping to change at page 10, line 34
algorithm that is not included in this set. The message digesting algorithm that is not included in this set. The message digesting
process is described in Section 5.4. process is described in Section 5.4.
encapContentInfo is the signed content, consisting of a content encapContentInfo is the signed content, consisting of a content
type identifier and the content itself. Details of the type identifier and the content itself. Details of the
EncapsulatedContentInfo type are discussed in section 5.2. EncapsulatedContentInfo type are discussed in section 5.2.
certificates is a collection of certificates. It is intended that certificates is a collection of certificates. It is intended that
the set of certificates be sufficient to contain certification the set of certificates be sufficient to contain certification
paths from a recognized "root" or "top-level certification paths from a recognized "root" or "top-level certification
authority" to all of the authority" to all of the signers in the signerInfos field. There
may be more certificates than necessary, and there may be
signers in the signerInfos field. There may be more certificates certificates sufficient to contain certification paths from two or
than necessary, and there may be certificates sufficient to more independent top-level certification authorities. There may
contain certification paths from two or more independent top-level also be fewer certificates than necessary, if it is expected that
certification authorities. There may also be fewer certificates recipients have an alternate means of obtaining necessary
than necessary, if it is expected that recipients have an certificates (e.g., from a previous set of certificates). The
alternate means of obtaining necessary certificates (e.g., from a signer's certificate MAY be included. The use of version 1
previous set of certificates). The signer's certificate MAY be attribute certificates is strongly discouraged.
included. The use of version 1 attribute certificates is strongly
discouraged.
crls is a collection of revocation status information. It is crls is a collection of revocation status information. It is
intended that the collection contain information sufficient to intended that the collection contain information sufficient to
determine whether the certificates in the certificates field are determine whether the certificates in the certificates field are
valid, but such correspondence is not necessary. Certificate valid, but such correspondence is not necessary. Certificate
revocation lists (CRLs) are the primary source of revocation revocation lists (CRLs) are the primary source of revocation
status information. There MAY be more CRLs than necessary, and status information. There MAY be more CRLs than necessary, and
there MAY also be fewer CRLs than necessary. there MAY also be fewer CRLs than necessary.
signerInfos is a collection of per-signer information. There MAY signerInfos is a collection of per-signer information. There MAY
skipping to change at page 12, line 18 skipping to change at page 13, line 10
the CMS SignedData encapContentInfo eContent OCTET STRING syntax, the CMS SignedData encapContentInfo eContent OCTET STRING syntax,
then the implementation MAY attempt to decode the SignedData type then the implementation MAY attempt to decode the SignedData type
using the PKCS #7 SignedData contentInfo content ANY syntax and using the PKCS #7 SignedData contentInfo content ANY syntax and
compute the message digest accordingly. compute the message digest accordingly.
The following strategy can be used to achieve backward compatibility The following strategy can be used to achieve backward compatibility
with PKCS #7 when creating a SignedData content type in which the with PKCS #7 when creating a SignedData content type in which the
encapsulated content is not formatted using the Data type. encapsulated content is not formatted using the Data type.
Implementations MAY examine the value of the eContentType, and then Implementations MAY examine the value of the eContentType, and then
adjust the expected DER encoding of eContent based on the object adjust the expected DER encoding of eContent based on the object
identifier value. For example, to support Microsoft AuthentiCode, identifier value. For example, to support Microsoft Authenticode
the following information MAY be included: [MSAC], the following information MAY be included:
eContentType Object Identifier is set to { 1 3 6 1 4 1 311 2 1 4 } eContentType Object Identifier is set to { 1 3 6 1 4 1 311 2 1 4 }
eContent contains DER encoded AuthentiCode signing information eContent contains DER encoded Authenticode signing information
5.3 SignerInfo Type 5.3 SignerInfo Type
Per-signer information is represented in the type SignerInfo: Per-signer information is represented in the type SignerInfo:
SignerInfo ::= SEQUENCE { SignerInfo ::= SEQUENCE {
version CMSVersion, version CMSVersion,
sid SignerIdentifier, sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier, digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
skipping to change at page 16, line 25 skipping to change at page 17, line 19
content-type attribute value MUST match the SignedData content-type attribute value MUST match the SignedData
encapContentInfo eContentType value. encapContentInfo eContentType value.
6. Enveloped-data Content Type 6. Enveloped-data Content Type
The enveloped-data content type consists of an encrypted content of The enveloped-data content type consists of an encrypted content of
any type and encrypted content-encryption keys for one or more any type and encrypted content-encryption keys for one or more
recipients. The combination of the encrypted content and one recipients. The combination of the encrypted content and one
encrypted content-encryption key for a recipient is a "digital encrypted content-encryption key for a recipient is a "digital
envelope" for that recipient. Any type of content can be enveloped envelope" for that recipient. Any type of content can be enveloped
for an arbitrary number of recipients using any of the three key for an arbitrary number of recipients using any of the supported key
management techniques for each recipient. management techniques for each recipient.
The typical application of the enveloped-data content type will The typical application of the enveloped-data content type will
represent one or more recipients' digital envelopes on content of the represent one or more recipients' digital envelopes on content of the
data or signed-data content types. data or signed-data content types.
Enveloped-data is constructed by the following steps: Enveloped-data is constructed by the following steps:
1. A content-encryption key for a particular content-encryption 1. A content-encryption key for a particular content-encryption
algorithm is generated at random. algorithm is generated at random.
skipping to change at page 23, line 10 skipping to change at page 24, line 5
to the appropriate certificate field. The originatorKey to the appropriate certificate field. The originatorKey
alternative includes the algorithm identifier and sender's key alternative includes the algorithm identifier and sender's key
agreement public key. This alternative permits originator agreement public key. This alternative permits originator
anonymity since the public key is not certified. Implementations anonymity since the public key is not certified. Implementations
MUST support all three alternatives for specifying the sender's MUST support all three alternatives for specifying the sender's
public key. public key.
ukm is optional. With some key agreement algorithms, the sender ukm is optional. With some key agreement algorithms, the sender
provides a User Keying Material (UKM) to ensure that a different provides a User Keying Material (UKM) to ensure that a different
key is generated each time the same two parties generate a key is generated each time the same two parties generate a
pairwise key. Implementations MUST support recipient processing pairwise key. Implementations MUST accept a KeyAgreeRecipientInfo
of a KeyAgreeRecipientInfo SEQUENCE that includes a ukm field. SEQUENCE that includes a ukm field. Implementations that do not
Implementations that do not support key agreement algorithms that support key agreement algorithms that make use of UKMs MUST
make use of UKMs MUST gracefully handle the presence of UKMs. gracefully handle the presence of UKMs.
keyEncryptionAlgorithm identifies the key-encryption algorithm, keyEncryptionAlgorithm identifies the key-encryption algorithm,
and any associated parameters, used to encrypt the content- and any associated parameters, used to encrypt the content-
encryption key with the key-encryption key. The key-encryption encryption key with the key-encryption key. The key-encryption
process is described in Section 6.4. process is described in Section 6.4.
recipientEncryptedKeys includes a recipient identifier and recipientEncryptedKeys includes a recipient identifier and
encrypted key for one or more recipients. The encrypted key for one or more recipients. The
KeyAgreeRecipientIdentifier is a CHOICE with two alternatives KeyAgreeRecipientIdentifier is a CHOICE with two alternatives
specifying the recipient's certificate, and thereby the specifying the recipient's certificate, and thereby the
skipping to change at page 40, line 42 skipping to change at page 41, line 36
utcTime UTCTime, utcTime UTCTime,
generalizedTime GeneralizedTime } generalizedTime GeneralizedTime }
Note: The definition of Time matches the one specified in the 1997 Note: The definition of Time matches the one specified in the 1997
version of X.509 [X.509-97]. version of X.509 [X.509-97].
Dates between 1 January 1950 and 31 December 2049 (inclusive) MUST be Dates between 1 January 1950 and 31 December 2049 (inclusive) MUST be
encoded as UTCTime. Any dates with year values before 1950 or after encoded as UTCTime. Any dates with year values before 1950 or after
2049 MUST be encoded as GeneralizedTime. 2049 MUST be encoded as GeneralizedTime.
UTCTime values MUST be expressed in Greenwich Mean Time (Zulu) and UTCTime values MUST be expressed in Coordinated Universal Time
(formerly known as Greenwich Mean Time (GMT) and Zulu clock time) and
MUST include seconds (i.e., times are YYMMDDHHMMSSZ), even where the MUST include seconds (i.e., times are YYMMDDHHMMSSZ), even where the
number of seconds is zero. Midnight MUST be represented as
number of seconds is zero. Midnight (GMT) MUST be represented as
"YYMMDD000000Z". Century information is implicit, and the century "YYMMDD000000Z". Century information is implicit, and the century
MUST be determined as follows: MUST be determined as follows:
Where YY is greater than or equal to 50, the year MUST be Where YY is greater than or equal to 50, the year MUST be
interpreted as 19YY; and interpreted as 19YY; and
Where YY is less than 50, the year MUST be interpreted as 20YY. Where YY is less than 50, the year MUST be interpreted as 20YY.
GeneralizedTime values MUST be expressed in Greenwich Mean Time GeneralizedTime values MUST be expressed in Coordinated Universal
(Zulu) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), Time and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even
even where the number of seconds is zero. GeneralizedTime values where the number of seconds is zero. GeneralizedTime values MUST NOT
MUST NOT include fractional seconds. include fractional seconds.
A signing-time attribute MUST have a single attribute value, even A signing-time attribute MUST have a single attribute value, even
though the syntax is defined as a SET OF AttributeValue. There MUST though the syntax is defined as a SET OF AttributeValue. There MUST
NOT be zero or multiple instances of AttributeValue present. NOT be zero or multiple instances of AttributeValue present.
The SignedAttributes syntax and the AuthAttributes syntax are each The SignedAttributes syntax and the AuthAttributes syntax are each
defined as a SET OF Attributes. The SignedAttributes in a signerInfo defined as a SET OF Attributes. The SignedAttributes in a signerInfo
MUST NOT include multiple instances of the signing-time attribute. MUST NOT include multiple instances of the signing-time attribute.
Similarly, the AuthAttributes in an AuthenticatedData MUST NOT Similarly, the AuthAttributes in an AuthenticatedData MUST NOT
include multiple instances of the signing-time attribute. include multiple instances of the signing-time attribute.
skipping to change at page 52, line 19 skipping to change at page 52, line 35
[CMS1] Housley, R., "Cryptographic Message Syntax", [CMS1] Housley, R., "Cryptographic Message Syntax",
RFC 2630, June 1999. RFC 2630, June 1999.
[CMS2] Housley, R., "Cryptographic Message Syntax", [CMS2] Housley, R., "Cryptographic Message Syntax",
RFC 3369, August 2002. RFC 3369, August 2002.
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) [CMSALG] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002. Algorithms", RFC 3370, August 2002.
[DSS] National Institute of Standards and Technology.
FIPS Pub 186: Digital Signature Standard. 19 May 1994.
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME", [ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999. RFC 2634, June 1999.
[MSAC] Microsoft Development Network (MSDN) Library,
"Authenticode", April 2004 Release.
[MSG] Ramsdell, B., "S/MIME Version 3 Message Specification", [MSG] Ramsdell, B., "S/MIME Version 3 Message Specification",
RFC 2633, June 1999. RFC 2633, June 1999.
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and
C. Adams, "X.509 Internet Public Key Infrastructure C. Adams, "X.509 Internet Public Key Infrastructure
Online Certificate Status Protocol - OCSP", RFC 2560, Online Certificate Status Protocol - OCSP", RFC 2560,
June 1999. June 1999.
[OLDMSG] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and [OLDMSG] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and
L. Repka, "S/MIME Version 2 Message Specification", L. Repka, "S/MIME Version 2 Message Specification",
skipping to change at page 53, line 51 skipping to change at page 54, line 19
Implementations must randomly generate content-encryption keys, Implementations must randomly generate content-encryption keys,
message-authentication keys, initialization vectors (IVs), and message-authentication keys, initialization vectors (IVs), and
padding. Also, the generation of public/private key pairs relies on padding. Also, the generation of public/private key pairs relies on
a random numbers. The use of inadequate pseudo-random number a random numbers. The use of inadequate pseudo-random number
generators (PRNGs) to generate cryptographic keys can result in generators (PRNGs) to generate cryptographic keys can result in
little or no security. An attacker may find it much easier to little or no security. An attacker may find it much easier to
reproduce the PRNG environment that produced the keys, searching the reproduce the PRNG environment that produced the keys, searching the
resulting small set of possibilities, rather than brute force resulting small set of possibilities, rather than brute force
searching the whole key space. The generation of quality random searching the whole key space. The generation of quality random
numbers is difficult. RFC 1750 [RANDOM] offers important guidance numbers is difficult. RFC 1750 [RANDOM] offers important guidance in
in this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one this area.
quality PRNG technique.
When using key agreement algorithms or previously distributed When using key agreement algorithms or previously distributed
symmetric key-encryption keys, a key-encryption key is used to symmetric key-encryption keys, a key-encryption key is used to
encrypt the content-encryption key. If the key-encryption and encrypt the content-encryption key. If the key-encryption and
content-encryption algorithms are different, the effective security content-encryption algorithms are different, the effective security
is determined by the weaker of the two algorithms. If, for example, is determined by the weaker of the two algorithms. If, for example,
content is encrypted with Triple-DES using a 168-bit Triple-DES content is encrypted with Triple-DES using a 168-bit Triple-DES
content-encryption key, and the content-encryption key is wrapped content-encryption key, and the content-encryption key is wrapped
with RC2 using a 40-bit RC2 key-encryption key, then at most 40 bits with RC2 using a 40-bit RC2 key-encryption key, then at most 40 bits
of protection is provided. A trivial search to determine the value of protection is provided. A trivial search to determine the value
 End of changes. 

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