draft-ietf-smime-cms-auth-enveloped-06.txt   rfc5083.txt 
S/MIME Working Group R. Housley Network Working Group R. Housley
Internet-Draft Vigil Security Request for Comments: 5083 Vigil Security
Updates: 3852 (if approved) 21 September 2007 Updates: 3852 November 2007
Intended status: Proposed Standard Category: Standards Track
Cryptographic Message Syntax (CMS) Cryptographic Message Syntax (CMS)
Authenticated-Enveloped-Data Content Type Authenticated-Enveloped-Data Content Type
<draft-ietf-smime-cms-auth-enveloped-06.txt>
Status of this Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at This document specifies an Internet standards track protocol for the
http://www.ietf.org/shadow.html Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract Abstract
This document describes an additional content type for the This document describes an additional content type for the
Cryptographic Message Syntax (CMS). The authenticated-enveloped-data Cryptographic Message Syntax (CMS). The authenticated-enveloped-data
content type is intended for use with authenticated encryption modes. content type is intended for use with authenticated encryption modes.
All of the various key management techniques that are supported in All of the various key management techniques that are supported in
the CMS enveloped-data content type are also supported by the CMS the CMS enveloped-data content type are also supported by the CMS
authenticated-enveloped-data content type. authenticated-enveloped-data content type.
1. Introduction 1. Introduction
This document describes an additional content type for the This document describes an additional content type for the
Cryptographic Message Syntax (CMS) [CMS]. The authenticated- Cryptographic Message Syntax (CMS) [CMS]. The authenticated-
enveloped-data content type is intended for use with authenticated enveloped-data content type is intended for use with authenticated
encryption modes, where an arbitrary content is both authenticated encryption modes, where an arbitrary content is both authenticated
and encrypted. Also, some associated data, in the form of and encrypted. Also, some associated data in the form of
authenticated attributes can also be authenticated. All of the authenticated attributes can also be authenticated. All of the
various key management techniques that are supported in the CMS various key management techniques that are supported in the CMS
enveloped-data content type are also supported by the CMS enveloped-data content type are also supported by the CMS
authenticated-enveloped-data content type. authenticated-enveloped-data content type.
The conventions for using the AES-CCM and the AES-GCM authenticated The conventions for using the Advanced Encryption Standard-Counter
encryption algorithms with the CMS authenticated-enveloped-data with Cipher Block Chaining-Message Authentication Code (AES-CCM) and
content type defined in this document can be found in [AESALGS]. the AES-Galois/Counter Mode (GCM) authenticated encryption algorithms
with the CMS authenticated-enveloped-data content type defined in
this document can be found in [AESALGS].
The authenticated-enveloped-data content type, like all of the other The authenticated-enveloped-data content type, like all of the other
CMS content types, employs ASN.1 [X.208-88], and it uses both the CMS content types, employs ASN.1 [X.208-88], and it uses both the
Basic Encoding Rules [X.209-88] and the Distinguished Encoding Rules Basic Encoding Rules (BER) [X.209-88] and the Distinguished Encoding
(DER) [X.509-88]. Rules (DER) [X.509-88].
1.1 Terminology 1.1. 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.2 Version Numbers 1.2. Version Numbers
The major data structure (AuthEnvelopedData) includes a version The major data structure (AuthEnvelopedData) includes a version
number as the first item in the data structure. The version number number as the first item in the data structure. The version number
is intended to avoid ASN.1 decode errors. Some implementations do is intended to avoid ASN.1 decode errors. Some implementations do
not check the version number prior to attempting a decode, and then not check the version number prior to attempting a decode, and then
if a decode error occurs, the version number is checked as part of if a decode error occurs, the version number is checked as part of
the error handling routine. This is a reasonable approach; it places the error handling routine. This is a reasonable approach; it places
error processing outside of the fast path. This approach is also error processing outside of the fast path. This approach is also
forgiving when an incorrect version number is used by the sender. forgiving when an incorrect version number is used by the sender.
Whenever the structure is updated, a higher version number will be Whenever the structure is updated, a higher version number will be
assigned. However, to ensure maximum interoperability the higher assigned. However, to ensure maximum interoperability, the higher
version number is only used when the new syntax feature is employed. version number is only used when the new syntax feature is employed.
That is, the lowest version number that supports the generated syntax That is, the lowest version number that supports the generated syntax
is used. is used.
2. Authenticated-enveloped-data Content Type 2. Authenticated-Enveloped-Data Content Type
The authenticated-enveloped-data content type consists of an The authenticated-enveloped-data content type consists of an
authenticated and encrypted content of any type and encrypted authenticated and encrypted content of any type and encrypted
content-authenticated-encryption keys for one or more recipients. content-authenticated-encryption keys for one or more recipients.
The combination of the authenticated and encrypted content and one The combination of the authenticated and encrypted content and one
encrypted content-authenticated-encryption key for a recipient is a encrypted content-authenticated-encryption key for a recipient is a
"digital envelope" for that recipient. Any type of content can be "digital envelope" for that recipient. Any type of content can be
enveloped for an arbitrary number of recipients using any of the enveloped for an arbitrary number of recipients using any of the
supported key management techniques for each recipient. In addition, supported key management techniques for each recipient. In addition,
authenticated but not encrypted attributes may be provided by the authenticated but not encrypted attributes may be provided by the
originator. originator.
The typical application of the authenticated-enveloped-data content The typical application of the authenticated-enveloped-data content
type will represent one or more recipients' digital envelopes on an type will represent one or more recipients' digital envelopes on an
encapsulated content. encapsulated content.
Authenticated-enveloped-data is constructed by the following steps: Authenticated-enveloped-data is constructed by the following steps:
1. A content-authenticated-encryption key for a particular 1. A content-authenticated-encryption key for a particular content-
content-authenticated-encryption algorithm is generated at random. authenticated-encryption algorithm is generated at random.
2. The content-authenticated-encryption key is encrypted for each 2. The content-authenticated-encryption key is encrypted for each
recipient. The details of this encryption depend on the key recipient. The details of this encryption depend on the key
management algorithm used, but four general techniques are management algorithm used, but four general techniques are
supported: supported:
key transport: the content-authenticated-encryption key is Key Transport: the content-authenticated-encryption key is
encrypted in the recipient's public key; encrypted in the recipient's public key;
key agreement: the recipient's public key and the sender's Key Agreement: the recipient's public key and the sender's
private key are used to generate a pairwise symmetric key- private key are used to generate a pairwise symmetric key-
encryption key, then the content-authenticated-encryption encryption key, then the content-authenticated-encryption
key is encrypted in the pairwise symmetric key-encryption key is encrypted in the pairwise symmetric key-encryption
key; key;
symmetric key-encryption keys: the content-authenticated- Symmetric Key-Encryption Keys: the content-authenticated-
encryption key is encrypted in a previously distributed encryption key is encrypted in a previously distributed
symmetric key-encryption key; and symmetric key-encryption key; and
passwords: the content-authenticated-encryption key is Passwords: the content-authenticated-encryption key is
encrypted in a key-encryption key that is derived from a encrypted in a key-encryption key that is derived from a
password or other shared secret value. password or other shared secret value.
3. For each recipient, the encrypted content-authenticated- 3. For each recipient, the encrypted content-authenticated-
encryption key and other recipient-specific information are encryption key and other recipient-specific information are
collected into a RecipientInfo value, defined in Section 6.2 of collected into a RecipientInfo value, defined in Section 6.2 of
[CMS]. [CMS].
4. Any attributes that are to be authenticated but not encrypted 4. Any attributes that are to be authenticated but not encrypted are
are collected in the authenticated attributes. collected in the authenticated attributes.
5. The attributes collected in step 4 are authenticated and the 5. The attributes collected in step 4 are authenticated and the CMS
CMS content is authenticated and encrypted with the content- content is authenticated and encrypted with the content-
authenticated-encryption key. If the authenticated encryption authenticated-encryption key. If the authenticated encryption
algorithm requires either the additional authenticated data (AAD) algorithm requires either the additional authenticated data (AAD)
or the content to be padded to a multiple of some block size, then or the content to be padded to a multiple of some block size,
the padding is added as described in Section 6.3 of [CMS]. then the padding is added as described in Section 6.3 of [CMS].
6. Any attributes that are to be provided without authentication 6. Any attributes that are to be provided without authentication or
or encryption are collected in the unauthenticated attributes. encryption are collected in the unauthenticated attributes.
7. The RecipientInfo values for all the recipients, the 7. The RecipientInfo values for all the recipients, the
authenticated attributes, then unauthenticated attributes, and the authenticated attributes, the unauthenticated attributes, and the
authenticated and encrypted content are collected together to form authenticated and encrypted content are collected together to
an AuthEnvelopedData value as defined in Section 2.1. form an AuthEnvelopedData value as defined in Section 2.1.
A recipient opens the digital envelope by decrypting one of the A recipient opens the digital envelope by decrypting one of the
encrypted content-authenticated-encryption keys, and then using the encrypted content-authenticated-encryption keys, and then using the
recovered key to decrypt and verify the integrity of the recovered key to decrypt and verify the integrity of the
authenticated and encrypted content as well as verifying the authenticated and encrypted content as well as to verify the
integrity of the authenticated attributes. integrity of the authenticated attributes.
The recipient MUST verify the integrity of the received content The recipient MUST verify the integrity of the received content
before releasing any information, especially the plaintext of the before releasing any information, especially the plaintext of the
content. If the integrity verification fails, the receiver MUST content. If the integrity verification fails, the receiver MUST
destroy all of the plaintext of the content. destroy all of the plaintext of the content.
This section is divided into three parts. The first part describes This section is divided into three parts. The first part describes
the AuthEnvelopedData content type, the second part describes the the AuthEnvelopedData content type, the second part describes the
authentication and encryption process, and third part describes the authentication and encryption process, and the third part describes
key encryption process. the key encryption process.
2.1 AuthEnvelopedData Type 2.1. AuthEnvelopedData Type
The following object identifier identifies the authenticated- The following object identifier identifies the authenticated-
enveloped-data content type: enveloped-data content type:
id-ct-authEnvelopedData OBJECT IDENTIFIER ::= { iso(1) id-ct-authEnvelopedData OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) ct(1) 23 } smime(16) ct(1) 23 }
The authenticated-enveloped-data content type MUST have ASN.1 type The authenticated-enveloped-data content type MUST have ASN.1 type
AuthEnvelopedData: AuthEnvelopedData:
skipping to change at page 5, line 32 skipping to change at page 4, line 48
authAttrs [1] IMPLICIT AuthAttributes OPTIONAL, authAttrs [1] IMPLICIT AuthAttributes OPTIONAL,
mac MessageAuthenticationCode, mac MessageAuthenticationCode,
unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL } unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL }
The fields of type AuthEnvelopedData have the following meanings: The fields of type AuthEnvelopedData have the following meanings:
version is the syntax version number. It MUST be set to 0. version is the syntax version number. It MUST be set to 0.
originatorInfo optionally provides information about the originatorInfo optionally provides information about the
originator. It is present only if required by the key originator. It is present only if required by the key
management algorithm. It may contain certificates and CRLs, management algorithm. It may contain certificates and
and the OriginatorInfo type is defined in Section 6.1 of [CMS]. Certificate Revocation Lists (CRLs), and the OriginatorInfo
type is defined in Section 6.1 of [CMS].
recipientInfos is a collection of per-recipient information. recipientInfos is a collection of per-recipient information.
There MUST be at least one element in the collection. The There MUST be at least one element in the collection. The
RecipientInfo type is defined in Section 6.2 of [CMS]. RecipientInfo type is defined in Section 6.2 of [CMS].
authEncryptedContentInfo is the authenticated and encrypted authEncryptedContentInfo is the authenticated and encrypted
content. The CMS enveloped-data content type uses the same content. The CMS enveloped-data content type uses the same
type to carry the encrypted content. The EncryptedContentInfo type to carry the encrypted content. The EncryptedContentInfo
type is defined in Section 6.1 of [CMS]. type is defined in Section 6.1 of [CMS].
skipping to change at page 6, line 33 skipping to change at page 5, line 52
If the authenticated encryption algorithm requires the content to be If the authenticated encryption algorithm requires the content to be
padded to a multiple of some block size, then the padding MUST be padded to a multiple of some block size, then the padding MUST be
added as described in Section 6.3 of [CMS]. This padding method is added as described in Section 6.3 of [CMS]. This padding method is
well defined if and only if the block size is less than 256 octets. well defined if and only if the block size is less than 256 octets.
If optional authenticated attributes are present, then they are DER If optional authenticated attributes are present, then they are DER
encoded. A separate encoding of the authAttrs field is performed to encoded. A separate encoding of the authAttrs field is performed to
construct the authenticated associated data (AAD) input to the construct the authenticated associated data (AAD) input to the
authenticated encryption algorithm. For the purposes of constructing authenticated encryption algorithm. For the purposes of constructing
the AAD, the IMPLICIT [1] tag in for authAttrs field is not used for the AAD, the IMPLICIT [1] tag in the authAttrs field is not used for
the DER encoding, rather an universal SET OF tag is used. That is, the DER encoding: rather a universal SET OF tag is used. That is,
the DER encoding of the SET OF tag, rather than of the IMPLICIT [1] the DER encoding of the SET OF tag, rather than of the IMPLICIT [1]
tag, is to be included in the construction for the AAD along with the tag, is to be included in the construction for the AAD along with the
length and content octets of the authAttrs value. If the length and content octets of the authAttrs value. If the
authenticated encryption algorithm requires the AAD to be padded to a authenticated encryption algorithm requires the AAD to be padded to a
multiple of some block size, then the padding MUST be added as multiple of some block size, then the padding MUST be added as
described in Section 6.3 of [CMS]. This padding method is well described in Section 6.3 of [CMS]. This padding method is well
defined if and only if block size is less than 256 octets. defined if and only if the block size is less than 256 octets.
If optional authenticated attributes are absent, then zero bits of If optional authenticated attributes are absent, then zero bits of
input are provided for the AAD input to the authenticated encryption input are provided for the AAD input to the authenticated encryption
algorithm. algorithm.
The inputs to the authenticated encryption algorithm are the content The inputs to the authenticated encryption algorithm are the content
(the data, which is padded if necessary), the DER-encoded (the data, which is padded if necessary), the DER-encoded
authenticated attributes (the AAD, which is padded if necessary), and authenticated attributes (the AAD, which is padded if necessary), and
the content-authenticated-encryption key. Under control of a the content-authenticated-encryption key. Under control of a
content-authenticated-encryption key, the authenticated encryption content-authenticated-encryption key, the authenticated encryption
skipping to change at page 7, line 27 skipping to change at page 6, line 46
each recipient of the same encrypted content. each recipient of the same encrypted content.
3. Security Considerations 3. Security Considerations
This specification defines an additional CMS content type. The This specification defines an additional CMS content type. The
security considerations provided in [CMS] apply to this content type security considerations provided in [CMS] apply to this content type
as well. as well.
Many authenticated encryption algorithms make use of a block cipher Many authenticated encryption algorithms make use of a block cipher
in counter mode to provide encryption. When used properly, counter in counter mode to provide encryption. When used properly, counter
mode provides strong confidentiality. Bellare, Desai, Jokipii, mode provides strong confidentiality. Bellare, Desai, Jokipii, and
Rogaway show in [BDJR] that the privacy guarantees provided by Rogaway show in [BDJR] that the privacy guarantees provided by
counter mode are at least as strong as those for CBC mode when using counter mode are at least as strong as those for Cipher Block
the same block cipher. Chaining (CBC) mode when using the same block cipher.
Unfortunately, it is easy to misuse counter mode. If counter block Unfortunately, it is easy to misuse counter mode. If counter block
values are ever used for more that one encryption operation with the values are ever used for more that one encryption operation with the
same key, then the same key stream will be used to encrypt both same key, then the same key stream will be used to encrypt both
plaintexts, and the confidentiality guarantees are voided. plaintexts, and the confidentiality guarantees are voided.
Fortunately, the CMS authenticated-enveloped-data content type Fortunately, the CMS authenticated-enveloped-data content type
provides all of the tools needed to avoid misuse of counter mode. provides all of the tools needed to avoid misuse of counter mode.
All of the existing key management techniques permit a fresh content- All of the existing key management techniques permit a fresh
encryption key to be generated for each content. In addition, content-encryption key to be generated for each content. In
existing authenticated encryption algorithms that make use of counter addition, existing authenticated encryption algorithms that make use
mode support the use of an unpredictable nonce value in the counter of counter mode support the use of an unpredictable nonce value in
block. This unpredictable nonce value (sometimes called a "salt") the counter block. This unpredictable nonce value (sometimes called
should be carried in an algorithm identifier parameter. a "salt") should be carried in an algorithm identifier parameter.
Implementations must randomly generate content-authenticated- Implementations must randomly generate content-authenticated-
encryption keys, padding, and unpredictable nonce values. Also, the encryption keys, padding, and unpredictable nonce values. Also, the
generation of public/private key pairs relies on a random numbers. generation of public/private key pairs relies on a random numbers.
The use of inadequate pseudo-random number generators (PRNGs) to The use of inadequate pseudo-random number generators (PRNGs) to
generate cryptographic keys can result in little or no security. An generate cryptographic keys can result in little or no security. An
attacker may find it much easier to reproduce the PRNG environment attacker may find it much easier to reproduce the PRNG environment
that produced the keys, searching the resulting small set of that produced the keys, and then searching the resulting small set of
possibilities, rather than brute force searching the whole key space. possibilities, rather than brute force searching the whole key space.
The generation of quality random numbers is difficult. RFC 4086 The generation of quality random numbers is difficult. RFC 4086
[RANDOM] offers important guidance in this area. [RANDOM] offers important guidance in this area.
If the message-digest attribute is included in the AuthAttributes, If the message-digest attribute is included in the AuthAttributes,
then the attribute value will contain the unencrypted one-way hash then the attribute value will contain the unencrypted one-way hash
value of the plaintext of the content. Disclosure of this hash value value of the plaintext of the content. Disclosure of this hash value
enables content tracking, and it can be used to determine if the enables content tracking, and it can be used to determine if the
plaintext matches one or more candidate contents. For these reasons, plaintext matches one or more candidate contents. For these reasons,
the AuthAttributes SHOULD NOT contain the message-digest attribute. the AuthAttributes SHOULD NOT contain the message-digest attribute.
CMS is often used to provide encryption in messaging environments. CMS is often used to provide encryption in messaging environments.
In messaging environments, various forms of unsolicited messages In messaging environments, various forms of unsolicited messages
(such as spam and phishing) represent a significant volume of (such as spam and phishing) represent a significant volume of
unwanted traffic. Present mitigation strategies for unwanted message unwanted traffic. Present mitigation strategies for unwanted message
traffic involve analysis of message plaintext. When recipients traffic involve analysis of message plaintext. When recipients
accept unsolicited encrypted messages, they become even more accept unsolicited encrypted messages, they become even more
vulnerable to unwanted traffic since the present mitigation vulnerable to unwanted traffic since many present mitigation
strategies will be unable to access the plaintext. Therefore, strategies will be unable to access the plaintext. Therefore,
software that receives messages that have been encrypted using CMS software that receives messages that have been encrypted using CMS
needs to provide one or more mechanisms to handle the unwanted needs to provide one or more mechanisms to handle the unwanted
message traffic. One approach that does not require disclosure of message traffic. One approach that does not require disclosure of
keying material to a server is to reject or discard encrypted keying material to a server is to reject or discard encrypted
messages unless they purport to come from a member of a white list. messages unless they purport to come from a member of a white list.
4. IANA Considerations 4. ASN.1 Module
None.
{{{ RFC Editor: Please remove this section prior to publication. }}}
5. ASN.1 Module
CMS-AuthEnvelopedData-2007 CMS-AuthEnvelopedData-2007
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) cms-authEnvelopedData(31) } pkcs-9(9) smime(16) modules(0) cms-authEnvelopedData(31) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS All -- EXPORTS All
-- The types and values defined in this module are exported for use -- The types and values defined in this module are exported for use
skipping to change at page 10, line 5 skipping to change at page 9, line 5
version CMSVersion, version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos, recipientInfos RecipientInfos,
authEncryptedContentInfo EncryptedContentInfo, authEncryptedContentInfo EncryptedContentInfo,
authAttrs [1] IMPLICIT AuthAttributes OPTIONAL, authAttrs [1] IMPLICIT AuthAttributes OPTIONAL,
mac MessageAuthenticationCode, mac MessageAuthenticationCode,
unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL } unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL }
END -- of CMS-AuthEnvelopedData-2007 END -- of CMS-AuthEnvelopedData-2007
6. References 5. References
6.1. Normative References 5.1. Normative References
[CMS] Housley, R., "Cryptographic Message Syntax", [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
RFC 3852, July 2004. 3852, July 2004.
[STDWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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). Encoding Rules for Abstract Syntax Notation One (ASN.1).
1988. 1988.
[X.509-88] CCITT. Recommendation X.509: The Directory - [X.509-88] CCITT. Recommendation X.509: The Directory -
Authentication Framework. 1988. Authentication Framework. 1988.
6.2. Informative References 5.2. Informative References
[AESALGS] Housley, R., "Using AES-CCM and AES-GCM Authenticated [AESALGS] Housley, R., "Using AES-CCM and AES-GCM Authenticated
Encryption in the Cryptographic Message Syntax (CMS)", Encryption in the Cryptographic Message Syntax (CMS)",
work in progress. draft-ietf-smime-cms-aes-ccm-and-gcm. RFC 5084, November 2007.
[BDJR] Bellare, M., Desai, A., Jokipii, E., and P. Rogaway, [BDJR] Bellare, M., Desai, A., Jokipii, E., and P. Rogaway, "A
"A Concrete Security Treatment of Symmetric Encryption: Concrete Security Treatment of Symmetric Encryption:
Analysis of the DES Modes of Operation", Proceedings Analysis of the DES Modes of Operation", Proceedings
38th Annual Symposium on Foundations of Computer 38th Annual Symposium on Foundations of Computer
Science, 1997. Science, 1997.
[RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
Recommendations for Security", RFC 4086, June 2005. "Randomness Requirements for Security", BCP 106, RFC
4086, June 2005.
7. Authors' Address Author's Address
Russell Housley Russell Housley
Vigil Security, LLC Vigil Security, LLC
918 Spring Knoll Drive 918 Spring Knoll Drive
Herndon, VA 20170 Herndon, VA 20170
USA USA
EMail: housley@vigilsec.com EMail: housley@vigilsec.com
Copyright and IPR Statements Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. ietf-ipr@ietf.org.
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 45 change blocks. 
92 lines changed or deleted 90 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/