draft-ietf-smime-rfc2630bis-06.txt   draft-ietf-smime-rfc2630bis-07.txt 
S/MIME Working Group R. Housley S/MIME Working Group R. Housley
Internet Draft RSA Laboratories Internet Draft RSA Laboratories
expires in six months December 2001 expires in six months February 2002
Will Obsolete: RFC 2630 and RFC 3211
Cryptographic Message Syntax Cryptographic Message Syntax
<draft-ietf-smime-rfc2630bis-06.txt> <draft-ietf-smime-rfc2630bis-07.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 1, line 34 skipping to change at page 1, line 35
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
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 messages. arbitrary message content.
This draft is being discussed on the "ietf-smime" mailing list. To
join the list, send a message to <ietf-smime-request@imc.org> with
the single word "subscribe" in the body of the message. Also, there
is a Web site for the mailing list at <http://www.imc.org/ietf-
smime/>.
Table of Contents Table of Contents
Status of this Memo ................................................ 1 Status of this Memo ................................................ 1
Abstract ........................................................... 1 Abstract ........................................................... 1
Table of Contents .................................................. 2 Table of Contents .................................................. 2
1 Introduction ................................................... 4 1 Introduction ................................................... 4
1.1 Changes Since RFC 2630 .................................... 4
1.2 Terminology ............................................... 5
2 General Overview ............................................... 5 2 General Overview ............................................... 5
3 General Syntax ................................................. 6 3 General Syntax ................................................. 6
4 Data Content Type .............................................. 6 4 Data Content Type .............................................. 6
5 Signed-data Content Type ....................................... 7 5 Signed-data Content Type ....................................... 7
5.1 SignedData Type ........................................... 8 5.1 SignedData Type ........................................... 8
5.2 EncapsulatedContentInfo Type .............................. 9 5.2 EncapsulatedContentInfo Type .............................. 9
5.2.1 Compatibility with PKCS #7 ......................... 10 5.2.1 Compatibility with PKCS #7 ......................... 10
5.3 SignerInfo Type ........................................... 11 5.3 SignerInfo Type ........................................... 11
5.4 Message Digest Calculation Process ........................ 13 5.4 Message Digest Calculation Process ........................ 13
5.5 Message Signature Generation Process ...................... 14 5.5 Signature Generation Process .............................. 14
5.6 Message Signature Verification Process .................... 15 5.6 Signature Verification Process ............................ 15
6 Enveloped-data Content Type .................................... 15 6 Enveloped-data Content Type .................................... 15
6.1 EnvelopedData Type ........................................ 16 6.1 EnvelopedData Type ........................................ 16
6.2 RecipientInfo Type ........................................ 19 6.2 RecipientInfo Type ........................................ 19
6.2.1 KeyTransRecipientInfo Type ......................... 19 6.2.1 KeyTransRecipientInfo Type ......................... 19
6.2.2 KeyAgreeRecipientInfo Type ......................... 20 6.2.2 KeyAgreeRecipientInfo Type ......................... 20
6.2.3 KEKRecipientInfo Type .............................. 23 6.2.3 KEKRecipientInfo Type .............................. 23
6.2.4 PasswordRecipientInfo Type ......................... 24 6.2.4 PasswordRecipientInfo Type ......................... 24
6.2.5 OtherRecipientInfo Type ............................ 24 6.2.5 OtherRecipientInfo Type ............................ 24
6.3 Content-encryption Process ................................ 25 6.3 Content-encryption Process ................................ 25
6.4 Key-encryption Process .................................... 25 6.4 Key-encryption Process .................................... 25
skipping to change at page 4, line 9 skipping to change at page 4, line 9
13 References ..................................................... 48 13 References ..................................................... 48
14 Security Considerations ........................................ 49 14 Security Considerations ........................................ 49
15 Acknowledgments ................................................ 51 15 Acknowledgments ................................................ 51
16 Author Address ................................................. 51 16 Author Address ................................................. 51
17 Full Copyright Statement ....................................... 52 17 Full Copyright Statement ....................................... 52
1 Introduction 1 Introduction
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 messages. arbitrary message content.
The CMS describes an encapsulation syntax for data protection. It The CMS describes an encapsulation syntax for data protection. It
supports digital signatures and encryption. The syntax allows supports digital signatures and encryption. The syntax allows
multiple encapsulations; one encapsulation envelope can be nested multiple encapsulations; one encapsulation envelope can be nested
inside another. Likewise, one party can digitally sign some inside another. Likewise, one party can digitally sign some
previously encapsulated data. It also allows arbitrary attributes, previously encapsulated data. It also allows arbitrary attributes,
such as signing time, to be signed along with the message content, such as signing time, to be signed along with the message content,
and provides for other attributes such as countersignatures to be and provides for other attributes such as countersignatures to be
associated with a signature. associated with a signature.
skipping to change at page 4, line 38 skipping to change at page 4, line 38
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 The CMS is derived from PKCS #7 version 1.5 as specified in RFC 2315
[PKCS#7]. Wherever possible, backward compatibility is preserved; [PKCS#7]. Wherever possible, backward compatibility is preserved;
however, changes were necessary to accommodate version 1 attribute however, changes were necessary to accommodate version 1 attribute
certificate transfer, key agreement and symmetric key-encryption key certificate transfer, key agreement and symmetric key-encryption key
techniques for key management. techniques for key management.
1.1 Changes Since RFC 2630
This document obsoletes RFC 2630 [OLDCMS] and RFC 3211 [PWRI]. This document obsoletes RFC 2630 [OLDCMS] 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. 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 using PKCS#7 version 1.5 and the CMS. These issues are
discussed in section 5.2.1. discussed in section 5.2.1.
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
cryptographic algorithms has been moved to a separate document
[CMSALG]. Separation of the protocol and algorithm specifications
allows the IETF to update each document independently. No mandatory
to implement algorithms are specified. Rather, protocols that rely
on the CMS are expected to choose appropriate algorithms for their
environment. The algorithms may be selected from [CMSALG] or
elsewhere.
The discussion of specific cryptographic algorithms has been moved to 1.2 Terminology
a separate document [CMSALG]. Separation of the protocol and
algorithm specifications allows the IETF to update each document
independently. No mandatory to implement algorithms are specified.
Rather, protocols that reply on the CMS are expected to choose
appropriate algorithms for their environment. The algorithms may be
selected from [CMSALG] or elsewhere.
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 by Scott Bradner in [STDWORDS]. described by Scott Bradner in [STDWORDS].
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
skipping to change at page 14, line 36 skipping to change at page 14, line 36
When the signedAttrs field is absent, only the octets comprising the When the signedAttrs field is absent, only the octets comprising the
value of the signedData encapContentInfo eContent OCTET STRING (e.g., value of the signedData encapContentInfo eContent OCTET STRING (e.g.,
the contents of a file) are input to the message digest calculation. the contents of a file) are input to the message digest calculation.
This has the advantage that the length of the content being signed This has the advantage that the length of the content being signed
need not be known in advance of the signature generation process. need not be known in advance of the signature generation process.
Although the encapContentInfo eContent OCTET STRING tag and length Although the encapContentInfo eContent OCTET STRING tag and length
octets are not included in the message digest calculation, they are octets are not included in the message digest calculation, they are
protected by other means. The length octets are protected by the protected by other means. The length octets are protected by the
nature of the message digest algorithm since it is computationally nature of the message digest algorithm since it is computationally
infeasible to find any two distinct messages of any length that have infeasible to find any two distinct message contents of any length
the same message digest. that have the same message digest.
5.5 Message Signature Generation Process 5.5 Signature Generation Process
The input to the signature generation process includes the result of The input to the signature generation process includes the result of
the message digest calculation process and the signer's private key. the message digest calculation process and the signer's private key.
The details of the signature generation depend on the signature The details of the signature generation depend on the signature
algorithm employed. The object identifier, along with any algorithm employed. The object identifier, along with any
parameters, that specifies the signature algorithm employed by the parameters, that specifies the signature algorithm employed by the
signer is carried in the signatureAlgorithm field. The signature signer is carried in the signatureAlgorithm field. The signature
value generated by the signer MUST be encoded as an OCTET STRING and value generated by the signer MUST be encoded as an OCTET STRING and
carried in the signature field. carried in the signature field.
5.6 Message Signature Verification Process 5.6 Signature Verification Process
The input to the signature verification process includes the result The input to the signature verification process includes the result
of the message digest calculation process and the signer's public of the message digest calculation process and the signer's public
key. The recipient MAY obtain the correct public key for the signer key. The recipient MAY obtain the correct public key for the signer
by any means, but the preferred method is from a certificate obtained by any means, but the preferred method is from a certificate obtained
from the SignedData certificates field. The selection and validation from the SignedData certificates field. The selection and validation
of the signer's public key MAY be based on certification path of the signer's public key MAY be based on certification path
validation (see [PROFILE]) as well as other external context, but is validation (see [PROFILE]) as well as other external context, but is
beyond the scope of this document. The details of the signature beyond the scope of this document. The details of the signature
verification depend on the signature algorithm employed. verification depend on the signature algorithm employed.
skipping to change at page 30, line 26 skipping to change at page 30, line 26
mac is the message authentication code. mac is the message authentication code.
unauthAttrs is a collection of attributes that are not unauthAttrs is a collection of attributes that are not
authenticated. The field is optional. To date, no attributes authenticated. The field is optional. To date, no attributes
have been defined for use as unauthenticated attributes, but other have been defined for use as unauthenticated attributes, but other
useful attribute types are defined in Section 11. useful attribute types are defined in Section 11.
9.2 MAC Generation 9.2 MAC Generation
The MAC calculation process computes a message authentication code The MAC calculation process computes a message authentication code
(MAC) on either the message being authenticated or a message digest (MAC) on either the content being authenticated or a message digest
of message being authenticated together with the originator's of content being authenticated together with the originator's
authenticated attributes. authenticated attributes.
If authAttrs field is absent, the input to the MAC calculation If authAttrs field is absent, the input to the MAC calculation
process is the value of the encapContentInfo eContent OCTET STRING. process is the value of the encapContentInfo eContent OCTET STRING.
Only the octets comprising the value of the eContent OCTET STRING are Only the octets comprising the value of the eContent OCTET STRING are
input to the MAC algorithm; the tag and the length octets are input to the MAC algorithm; the tag and the length octets are
omitted. This has the advantage that the length of the content being omitted. This has the advantage that the length of the content being
authenticated need not be known in advance of the MAC generation authenticated need not be known in advance of the MAC generation
process. process.
skipping to change at page 31, line 14 skipping to change at page 31, line 14
being authenticated. Specifically, the input is the encapContentInfo being authenticated. Specifically, the input is the encapContentInfo
eContent OCTET STRING to which the authentication process is applied. eContent OCTET STRING to which the authentication process is applied.
Only the octets comprising the value of the encapContentInfo eContent Only the octets comprising the value of the encapContentInfo eContent
OCTET STRING are input to the message digest algorithm, not the tag OCTET STRING are input to the message digest algorithm, not the tag
or the length octets. This has the advantage that the length of the or the length octets. This has the advantage that the length of the
content being authenticated need not be known in advance. Although content being authenticated need not be known in advance. Although
the encapContentInfo eContent OCTET STRING tag and length octets are the encapContentInfo eContent OCTET STRING tag and length octets are
not included in the message digest calculation, they are still not included in the message digest calculation, they are still
protected by other means. The length octets are protected by the protected by other means. The length octets are protected by the
nature of the message digest algorithm since it is computationally nature of the message digest algorithm since it is computationally
infeasible to find any two distinct messages of any length that have infeasible to find any two distinct contents of any length that have
the same message digest. the same message digest.
The input to the MAC calculation process includes the MAC input data, The input to the MAC calculation process includes the MAC input data,
defined above, and an authentication key conveyed in a recipientInfo defined above, and an authentication key conveyed in a recipientInfo
structure. The details of MAC calculation depend on the MAC structure. The details of MAC calculation depend on the MAC
algorithm employed (e.g., HMAC). The object identifier, along with algorithm employed (e.g., HMAC). The object identifier, along with
any parameters, that specifies the MAC algorithm employed by the any parameters, that specifies the MAC algorithm employed by the
originator is carried in the macAlgorithm field. The MAC value originator is carried in the macAlgorithm field. The MAC value
generated by the originator is encoded as an OCTET STRING and carried generated by the originator is encoded as an OCTET STRING and carried
in the mac field. in the mac field.
skipping to change at page 31, line 38 skipping to change at page 31, line 38
The input to the MAC verification process includes the input data The input to the MAC verification process includes the input data
(determined based on the presence or absence of the authAttrs field, (determined based on the presence or absence of the authAttrs field,
as defined in 9.2), and the authentication key conveyed in as defined in 9.2), and the authentication key conveyed in
recipientInfo. The details of the MAC verification process depend on recipientInfo. The details of the MAC verification process depend on
the MAC algorithm employed. the MAC algorithm employed.
The recipient MUST NOT rely on any MAC values or message digest The recipient MUST NOT rely on any MAC values or message digest
values computed by the originator. The content is authenticated as values computed by the originator. The content is authenticated as
described in section 9.2. If the originator includes authenticated described in section 9.2. If the originator includes authenticated
attributes, then the content of the authAttrs is authenticated as attributes, then the content of the authAttrs is authenticated as
described in section 9.2. For authentication to succeed, the message described in section 9.2. For authentication to succeed, the MAC
MAC value calculated by the recipient MUST be the same as the value value calculated by the recipient MUST be the same as the value of
of the mac field. Similarly, for authentication to succeed when the the mac field. Similarly, for authentication to succeed when the
authAttrs field is present, the content message digest value authAttrs field is present, the content message digest value
calculated by the recipient MUST be the same as the message digest calculated by the recipient MUST be the same as the message digest
value included in the authAttrs message-digest attribute. value included in the authAttrs message-digest attribute.
If the AuthenticatedData includes authAttrs, then the content-type If the AuthenticatedData includes authAttrs, then the content-type
attribute value MUST match the AuthenticatedData encapContentInfo attribute value MUST match the AuthenticatedData encapContentInfo
eContentType value. eContentType value.
10 Useful Types 10 Useful Types
skipping to change at page 32, line 23 skipping to change at page 32, line 23
All of the algorithm identifiers have the same type: All of the algorithm identifiers have the same type:
AlgorithmIdentifier. The definition of AlgorithmIdentifier is taken AlgorithmIdentifier. The definition of AlgorithmIdentifier is taken
from X.509 [X.509-88]. from X.509 [X.509-88].
There are many alternatives for each algorithm type. There are many alternatives for each algorithm type.
10.1.1 DigestAlgorithmIdentifier 10.1.1 DigestAlgorithmIdentifier
The DigestAlgorithmIdentifier type identifies a message-digest The DigestAlgorithmIdentifier type identifies a message-digest
algorithm. Examples include SHA-1, MD2, and MD5. A message-digest algorithm. Examples include SHA-1, MD2, and MD5. A message-digest
algorithm maps an octet string (the message) to another octet string algorithm maps an octet string (the content) to another octet string
(the message digest). (the message digest).
DigestAlgorithmIdentifier ::= AlgorithmIdentifier DigestAlgorithmIdentifier ::= AlgorithmIdentifier
10.1.2 SignatureAlgorithmIdentifier 10.1.2 SignatureAlgorithmIdentifier
The SignatureAlgorithmIdentifier type identifies a signature The SignatureAlgorithmIdentifier type identifies a signature
algorithm. Examples include RSA, DSA, and ECDSA. A signature algorithm. Examples include RSA, DSA, and ECDSA. A signature
algorithm supports signature generation and verification operations. algorithm supports signature generation and verification operations.
The signature generation operation uses the message digest and the The signature generation operation uses the message digest and the
skipping to change at page 33, line 14 skipping to change at page 33, line 14
derived from passwords are supported. derived from passwords are supported.
KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
10.1.4 ContentEncryptionAlgorithmIdentifier 10.1.4 ContentEncryptionAlgorithmIdentifier
The ContentEncryptionAlgorithmIdentifier type identifies a content- The ContentEncryptionAlgorithmIdentifier type identifies a content-
encryption algorithm. Examples include Triple-DES and RC2. A encryption algorithm. Examples include Triple-DES and RC2. A
content-encryption algorithm supports encryption and decryption content-encryption algorithm supports encryption and decryption
operations. The encryption operation maps an octet string (the operations. The encryption operation maps an octet string (the
message) to another octet string (the ciphertext) under control of a plaintext) to another octet string (the ciphertext) under control of
content-encryption key. The decryption operation is the inverse of a content-encryption key. The decryption operation is the inverse of
the encryption operation. Context determines which operation is the encryption operation. Context determines which operation is
intended. intended.
ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
10.1.5 MessageAuthenticationCodeAlgorithm 10.1.5 MessageAuthenticationCodeAlgorithm
The MessageAuthenticationCodeAlgorithm type identifies a message The MessageAuthenticationCodeAlgorithm type identifies a message
authentication code (MAC) algorithm. Examples include DES-MAC and authentication code (MAC) algorithm. Examples include DES-MAC and
HMAC-SHA-1. A MAC algorithm supports generation and verification HMAC-SHA-1. A MAC algorithm supports generation and verification
skipping to change at page 49, line 40 skipping to change at page 49, line 40
The Cryptographic Message Syntax provides a method for digitally The Cryptographic Message Syntax provides a method for digitally
signing data, digesting data, encrypting data, and authenticating signing data, digesting data, encrypting data, and authenticating
data. data.
Implementations must protect the signer's private key. Compromise of Implementations must protect the signer's private key. Compromise of
the signer's private key permits masquerade. the signer's private key permits masquerade.
Implementations must protect the key management private key, the key- Implementations must protect the key management private key, the key-
encryption key, and the content-encryption key. Compromise of the encryption key, and the content-encryption key. Compromise of the
key management private key or the key-encryption key may result in key management private key or the key-encryption key may result in
the disclosure of all messages protected with that key. Similarly, the disclosure of all contents protected with that key. Similarly,
compromise of the content-encryption key may result in disclosure of compromise of the content-encryption key may result in disclosure of
the associated encrypted content. the associated encrypted content.
Implementations must protect the key management private key and the Implementations must protect the key management private key and the
message-authentication key. Compromise of the key management private message-authentication key. Compromise of the key management private
key permits masquerade of authenticated data. Similarly, compromise key permits masquerade of authenticated data. Similarly, compromise
of the message-authentication key may result in undetectable of the message-authentication key may result in undetectable
modification of the authenticated content. modification of the authenticated content.
The key management technique employed to distribute message- The key management technique employed to distribute message-
authentication keys must itself provide data origin authentication, authentication keys must itself provide data origin authentication,
otherwise the message content is delivered with integrity from an otherwise the contents are delivered with integrity from an unknown
unknown source. Neither RSA [PKCS#1, NEWPKCS#1] nor Ephemeral-Static source. Neither RSA [PKCS#1, NEWPKCS#1] nor Ephemeral-Static Diffie-
Diffie-Hellman [DH-X9.42] provide the necessary data origin Hellman [DH-X9.42] provide the necessary data origin authentication.
authentication. Static-Static Diffie-Hellman [DH-X9.42] does provide Static-Static Diffie-Hellman [DH-X9.42] does provide the necessary
the necessary data origin authentication when both the originator and data origin authentication when both the originator and recipient
recipient public keys are bound to appropriate identities in X.509 public keys are bound to appropriate identities in X.509
certificates. certificates.
When more than two parties share the same message-authentication key, When more than two parties share the same message-authentication key,
data origin authentication is not provided. Any party that knows the data origin authentication is not provided. Any party that knows the
message-authentication key can compute a valid MAC, therefore the message-authentication key can compute a valid MAC, therefore the
message could originate from any one of the parties. contents could originate from any one of the parties.
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 in numbers is difficult. RFC 1750 [RANDOM] offers important guidance in
this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality
PRNG technique. 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,
a message content is encrypted with 168-bit Triple-DES and the content is encrypted with 168-bit Triple-DES and the Triple-DES
Triple-DES content-encryption key is wrapped with a 40-bit RC2 key, content-encryption key is wrapped with a 40-bit RC2 key, then at most
then at most 40 bits of protection is provided. A trivial search to 40 bits of protection is provided. A trivial search to determine the
determine the value of the 40-bit RC2 key can recover Triple-DES key, value of the 40-bit RC2 key can recover Triple-DES key, and then the
and then the Triple-DES key can be used to decrypt the content. Triple-DES key can be used to decrypt the content. Therefore,
Therefore, implementers must ensure that key-encryption algorithms implementers must ensure that key-encryption algorithms are as strong
are as strong or stronger than content-encryption algorithms. or stronger than content-encryption algorithms.
Implementers should be aware that cryptographic algorithms become Implementers should be aware that cryptographic algorithms become
weaker with time. As new cryptoanalysis techniques are developed and weaker with time. As new cryptoanalysis techniques are developed and
computing performance improves, the work factor to break a particular computing performance improves, the work factor to break a particular
cryptographic algorithm will reduce. Therefore, cryptographic cryptographic algorithm will reduce. Therefore, cryptographic
algorithm implementations should be modular allowing new algorithms algorithm implementations should be modular allowing new algorithms
to be readily inserted. That is, implementers should be prepared for to be readily inserted. That is, implementers should be prepared for
the set of mandatory to implement algorithms to change over time. the set of mandatory to implement algorithms to change over time.
The countersignature unsigned attribute includes a digital signature The countersignature unsigned attribute includes a digital signature
skipping to change at page 52, line 7 skipping to change at page 52, line 7
Russell Housley Russell Housley
RSA Laboratories RSA Laboratories
918 Spring Knoll Drive 918 Spring Knoll Drive
Herndon, VA 20170 Herndon, VA 20170
USA USA
rhousley@rsasecurity.com rhousley@rsasecurity.com
17 Full Copyright Statement 17 Full Copyright Statement
Copyright (C) The Internet Society (date). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. In addition, the included on all such copies and derivative works. In addition, the
ASN.1 module presented in Appendix A may be used in whole or in part ASN.1 module presented in Appendix A may be used in whole or in part
without inclusion of the copyright notice. However, this document without inclusion of the copyright notice. However, this document
itself may not be modified in any way, such as by removing the itself may not be modified in any way, such as by removing the
 End of changes. 

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