draft-ietf-smime-rcek-04.txt   rfc3185.txt 
INTERNET-DRAFT S. Farrell Network Working Group S. Farrell
Expires in six months Baltimore Technologies Request for Comments: 3185 Baltimore Technologies
S. Turner Category: Standards Track S. Turner
IECA IECA
May 28th 2001 October 2001
Reuse of CMS Content Encryption Keys Reuse of CMS Content Encryption Keys
<draft-ietf-smime-rcek-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document specifies an Internet standards track protocol for the
all provisions of Section 10 of [RFC2026]. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Internet-Drafts are working documents of the Internet Engineering Official Protocol Standards" (STD 1) for the standardization state
Task Force (IETF), its areas, and its working groups. Note that and status of this protocol. Distribution of this memo is unlimited.
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 Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2001). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
This note describes a way to include a key identifier in a CMS This document describes a way to include a key identifier in a CMS
enveloped data structure, so that the content encryption key can be (Cryptographic Message Syntax) enveloped data structure, so that the
re-used for further enveloped data packets. content encryption key can be re-used for further enveloped data
packets.
Table Of Contents Table Of Contents
Status of this Memo.............................................1 1. Introduction................................................... 2
Abstract........................................................1 2. Applicability.................................................. 2
Table Of Contents...............................................1 3. How to do it................................................... 3
1. Introduction.................................................2 4. Using different CEK and KEK algorithms......................... 4
2. Applicability................................................2 5. Conformance.................................................... 5
3. How to do it.................................................3 6. Security Considerations........................................ 5
4. Using different CEK and KEK algorithms.......................4 7. References..................................................... 6
5. Conformance..................................................5 Authors' Addresses................................................ 6
6. Security Considerations......................................5 Appendix A: ASN.1 Module.......................................... 7
7. References...................................................6 Full Copyright Statement.......................................... 10
Author's Addresses..............................................6
Full Copyright Statement........................................7
Appendix A: ASN.1 Module........................................7
Appendix B: Revision History...................................10
1. Introduction 1. Introduction
CMS [CMS] specifies EnvelopedData. EnvelopedData supports data CMS [CMS] specifies EnvelopedData. EnvelopedData supports data
encryption using either symmetric or asymmetric key management encryption using either symmetric or asymmetric key management
techniques. Since asymmetric key establishment is relatively techniques. Since asymmetric key establishment is relatively
expensive, it is desirable in some environments to re-use a shared expensive, it is desirable in some environments to re-use a shared
content-encryption key established using asymmetric mechanisms for content-encryption key established using asymmetric mechanisms for
encryption operations in subsequent messages. encryption operations in subsequent messages.
The basic idea here is to reuse the content encryption key (CEK) The basic idea here is to reuse the content-encryption key (CEK) from
from a message (say MSG1) to derive the key encryption key (KEK) for a message (say MSG1) to derive the key-encryption key (KEK) for a
a later message, (MSG2), by including a reference value for the CEK later message, (MSG2), by including a reference value for the CEK in
in message 1, and that same value as the KEKIdentifier for message message 1, and that same value as the KEKIdentifier for message 2.
2. The CEK from message 1 is called the "referenced CEK". The CEK from message 1 is called the "referenced CEK".
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
in this document are to be interpreted as described in [RFC2119]. in this document are to be interpreted as described in [RFC2119].
2. Applicability 2. Applicability
This specification is intended to be used to provide more efficient This specification is intended to be used to provide more efficient
selective field confidentiality between communicating peers, in selective field confidentiality between communicating peers, in
particular in the cases where: particular in the cases where:
- The originator is a client that wishes to send a number of fields - The originator is a client that wishes to send a number of fields
to a server (the recipient) in a single transaction, where the to a server (the recipient) in a single transaction, where the
referenced CEK is used for the separate encryption of each field. referenced CEK is used for the separate encryption of each field.
- The originator and recipient are servers that communicate very - The originator and recipient are servers that communicate very
frequently and use this specification purely for efficiency. frequently and use this specification purely for efficiency.
This specification is not intended to be applicable in all cases. It This specification is not intended to be applicable in all cases. It
is suited for use where: is suited for use where:
- Its use is further scoped: that is, this specification doesn't - Its use is further scoped: that is, this specification doesn't
define a protocol but merely a trick that can be used in a larger define a protocol but merely a trick that can be used in a larger
context and additional specification will be needed for each such context and additional specification will be needed for each such
case. In particular, in order to use this specification, it is case. In particular, in order to use this specification, it is
REQUIRED to define the originators' and recipients' behavior where REQUIRED to define the originators' and recipients' behavior where
a referenced CEK has been "lost". a referenced CEK has been "lost".
- This specification is not suitable for general group key - This specification is not suitable for general group key
management. management.
- The underlying cryptographic API is suitable: it is very likely - The underlying cryptographic API is suitable: it is very likely
that any cryptographic API that completely "hides" the bits of that any cryptographic API that completely "hides" the bits of
cryptographic keys from the CMS layer will prevent reuse of a cryptographic keys from the CMS layer will prevent reuse of a
referenced CEK (since they won't have a primitive that allows referenced CEK (since they won't have a primitive that allows
MSG1.CEK to be transformed to MSG2.KEK). MSG1.CEK to be transformed to MSG2.KEK).
- The algorithms for content and key encryption have compatible key - The algorithms for content and key encryption have compatible key
values and strengths, that is, if MSG1.contentEncryptionAlgorithm values and strengths, that is, if MSG1.contentEncryptionAlgorithm
is a 40bit cipher and MSG2.keyEncryptionAlgorithm requires 168 is a 40bit cipher and MSG2.keyEncryptionAlgorithm requires 168
bits of keying material, then this specification SHOULD NOT be bits of keying material, then this specification SHOULD NOT be
used. used.
There are other ways that could be envisaged to establish the There are other ways that could be envisaged to establish the
required symmetric keying material, e.g. by leveraging a group required symmetric keying material, e.g., by leveraging a group
keying scheme or by defining a content type that contains a KEK keying scheme or by defining a content type that contains a KEK
value. Although this scheme is much simpler than generic group key value. Although this scheme is much simpler than generic group key
management, if an implementation already supports group key management, if an implementation already supports group key
management then this scheme doesn't add value. This scheme is also management then this scheme doesn't add value. This scheme is also
suitable for inclusion in CMS libraries (though the addition of new suitable for inclusion in CMS libraries (though the addition of new
state might be a problem for some implementations), which can offer state might be a problem for some implementations), which can offer
some advantages over application layer schemes (e.g. where the some advantages over application layer schemes (e.g., where the
content includes MSG2.KEK). content includes MSG2.KEK).
3. How to do it 3. How to do it
In order to reference the content-encryption key (CEK) used in an In order to reference the content-encryption key (CEK) used in an
EnvelopedData, a key identifier can be included in the EnvelopedData, a key identifier can be included in the
unprotectedAttrs field of MSG1. This key can then be used to derive unprotectedAttrs field of MSG1. This key can then be used to derive
the key-encryption key (KEK) for other instances of EnvelopedData or the key-encryption key (KEK) for other instances of EnvelopedData or
for other purposes. If the CEK from MSG1 is to be used to derive the for other purposes. If the CEK from MSG1 is to be used to derive the
KEK for MSG2 then MSG1 MUST contain an unprotectedAttrs Attribute of KEK for MSG2 then MSG1 MUST contain an unprotectedAttrs Attribute of
type id-aa-CEKReference with a single value using the CEKReference type id-aa-CEKReference with a single value using the CEKReference
syntax. syntax.
MSG2.KEK is to be derived by reversing the bytes of MSG1.CEK. The MSG2.KEK is to be derived by reversing the bytes of MSG1.CEK. The
byte reversal is to avoid an attack where the attacker has a known byte reversal is to avoid an attack where the attacker has a known
plaintext and the related ciphertext (encrypted with MSG1.CEK) that plaintext and the related ciphertext (encrypted with MSG1.CEK) that
(otherwise) could be directly used as a MSG2.KEK. (otherwise) could be directly used as a MSG2.KEK.
The application MUST ensure that the relevant algorithms are The application MUST ensure that the relevant algorithms are
compatible. That is, a CEKReference attribute alone can only be used compatible. That is, a CEKReference attribute alone can only be used
where the content-encryption algorithm from MSG1 employs the same where the content-encryption algorithm from MSG1 employs the same
type of symmetric key as the key-encryption algorithm from MSG2. type of symmetric key as the key-encryption algorithm from MSG2.
Notes: Notes:
1) There is nothing to prevent inclusion of a CEKReference attribute 1) There is nothing to prevent inclusion of a CEKReference attribute
in MSG2 as well as in MSG1. That is, an originator could "roll" in MSG2 as well as in MSG1. That is, an originator could "roll"
the referenced CEK with every message. the referenced CEK with every message.
2) The CEKReference attribute can occur with any of the choices for 2) The CEKReference attribute can occur with any of the choices for
RecipientInfo: ktri, kari or kekri. Implementors MUST NOT assume RecipientInfo: ktri, kari or kekri. Implementors MUST NOT assume
that CEKReference can only occur where ktri or kari is used. that CEKReference can only occur where ktri or kari is used.
id-aa-CEKReference OBJECT IDENTIFIER ::= { id-aa 30 } id-aa-CEKReference OBJECT IDENTIFIER ::= { id-aa 30 }
CEKReference ::= OCTET STRING CEKReference ::= OCTET STRING
id-aa is an object identifier defined in [CMS-MSG]. id-aa is an object identifier defined in [CMS-MSG].
In order to allow the originator of MSG1 to indicate the "lifetime" In order to allow the originator of MSG1 to indicate the "lifetime"
of the CEK, the originator MAY include a CEKMaxDecrypts attribute, of the CEK, the originator MAY include a CEKMaxDecrypts attribute,
also in the unprotectedAttrs field of EnvelopedData. This attribute also in the unprotectedAttrs field of EnvelopedData. This attribute
has an INTEGER syntax (the value MUST be >=1 and maximally 2^31), has an INTEGER syntax (the value MUST be >=1 and maximally 2^31), and
and indicates to the recipient the maximum number of messages indicates to the recipient the maximum number of messages (excluding
(excluding MSG1) that will use the referenced CEK. This Attribute MSG1) that will use the referenced CEK. This Attribute MUST only be
MUST only be sent when a CEKReference attribute is also included. sent when a CEKReference attribute is also included.
The recipient SHOULD maintain the CEKReference information The recipient SHOULD maintain the CEKReference information (minimally
(minimally the key identifier and the CEK value) while less than the key identifier and the CEK value) while less than maxDecrypt
maxDecrypt messages have been successfully received. Recipients messages have been successfully received. Recipients SHOULD delete
SHOULD delete the CEKReference information after some locally the CEKReference information after some locally configured period.
configured period.
When this attribute is not present, originators and recipients When this attribute is not present, originators and recipients SHOULD
SHOULD behave as if a value of one had been sent. behave as if a value of one had been sent.
id-aa-CEKMaxDecrypts OBJECT IDENTIFIER ::= { id-aa 31 } id-aa-CEKMaxDecrypts OBJECT IDENTIFIER ::= { id-aa 31 }
CEKMaxDecrypts ::= INTEGER CEKMaxDecrypts ::= INTEGER
If CEKMaxDecrypts is missing, or has the value one, then each CEK If CEKMaxDecrypts is missing, or has the value one, then each CEK
will be re-used once as the KEK for the next message. This means will be re-used once as the KEK for the next message. This means
that MSG[n].KEK is the byte-reversal of MSG[n-1].CEK; subsequently that MSG[n].KEK is the byte-reversal of MSG[n-1].CEK; subsequently
MSG[n+1].KEK will be the byte-reversal of MSG[n].CEK. Note that MSG[n+1].KEK will be the byte-reversal of MSG[n].CEK. Note that
MSG[n-1].CEK has no impact whatsoever to MSG[n+1], so long as CEKs MSG[n-1].CEK has no impact whatsoever to MSG[n+1], so long as CEKs
are generated randomly (and not e.g. derived from KEKs somehow). are generated randomly (and not e.g., derived from KEKs somehow).
4. Using different CEK and KEK algorithms 4. Using different CEK and KEK algorithms
Where MSG1.content-encryption algorithm and MSG2.key-encryption Where MSG1.content-encryption algorithm and MSG2.key-encryption
algorithm are the same then the MSG2.KEK is the byte-reverse of algorithm are the same then the MSG2.KEK is the byte-reverse of
MSG1.CEK. However, in general, these algorithms MAY differ, e.g. MSG1.CEK. However, in general, these algorithms MAY differ, e.g.,
requiring different key lengths. This section specifies a generic requiring different key lengths. This section specifies a generic
way to derive MSG2.KEK for such cases. way to derive MSG2.KEK for such cases.
Note: In some sense, the CEK and KEK algorithms are never the Note: In some sense, the CEK and KEK algorithms are never the "same",
"same", e.g. id-alg-CMS3DESwrap and des-ede3-cbc differ. However, e.g., id-alg-CMS3DESwrap and des-ede3-cbc differ. However, for the
for the purposes of this specification, all we care about is that purposes of this specification, all we care about is that the
the algorithms use the same format and size of keying material (see algorithms use the same format and size of keying material (see also
also security considerations) and that they do not differ security considerations) and that they do not differ significantly in
significantly in terms of the resulting cryptographic "strength". In terms of the resulting cryptographic "strength." In that sense the
that sense the two algorithms in the example above are the "same." two algorithms in the example above are the "same."
Implementations MAY include this functionality. Implementations MAY include this functionality.
The basic approach is to use the PBKDF2 key derivation function The basic approach is to use the PBKDF2 key derivation function
defined in PKCS#5 [RFC2898], but using MSG1.CEK as input instead of defined in PKCS#5 [RFC2898], but using MSG1.CEK as input instead of a
a password. The output of the PBKDF2 function is MSG2.KEK. To this password. The output of the PBKDF2 function is MSG2.KEK. To this
end, a new attribute type is defined which allows passing of the end, a new attribute type is defined which allows passing of the
required parameters. required parameters.
id-aa-KEKDerivationAlg OBJECT IDENTIFIER ::= { id-aa 32 } id-aa-KEKDerivationAlg OBJECT IDENTIFIER ::= { id-aa 32 }
KEKDerivationAlgorithm ::= SEQUENCE { KEKDerivationAlgorithm ::= SEQUENCE {
kekAlg AlgorithmIdentifier, kekAlg AlgorithmIdentifier,
pbkdf2Param PBKDF2-params pbkdf2Param PBKDF2-params
} }
kekAlg is the algorithm identifier (and associated parameters, if kekAlg is the algorithm identifier (and associated parameters, if
any), for the MSG2 key encryption algorithm. Note that it is not any), for the MSG2 key encryption algorithm. Note that it is not
necessary to protect this field since modification of keyAlg only necessary to protect this field since modification of keyAlg only
represents a denial-of-service attack. represents a denial-of-service attack.
The PBKDF2 algorithm parameters are to be handled as follows: The PBKDF2 algorithm parameters are to be handled as follows:
- The salt MUST use the "specified" element of the CHOICE. - The salt MUST use the "specified" element of the CHOICE.
- The message originator selects the iterationCount. - The message originator selects the iterationCount.
- The value of keyLength is determined by the kekAlg and MUST be - The value of keyLength is determined by the kekAlg and MUST be
present. present.
- The prf field MUST use the default algorithm specified in - The prf field MUST use the default algorithm specified in
[RFC2898] which is algid-hmacWithSHA1 (and so the prf field MUST [RFC2898] which is algid-hmacWithSHA1 (and so the prf field MUST
be omitted). be omitted).
5. Conformance 5. Conformance
This specification only applies to messages where the CEKReference This specification only applies to messages where the CEKReference
attribute is present. All attributes specified here SHOULD be attribute is present. All attributes specified here SHOULD be
ignored unless they are present in a message containing a valid, new ignored unless they are present in a message containing a valid, new
or recognized, existing value of CEKReference. The CEKMaxDecrypts or recognized, existing value of CEKReference. The CEKMaxDecrypts
attribute is to be treated by the recipient as a hint, but MUST be attribute is to be treated by the recipient as a hint, but MUST be
honored by the originator. honored by the originator.
The optional to implement KEKDerivationAlgorithm attribute MUST only The optional to implement KEKDerivationAlgorithm attribute MUST only
be present when MSG1.content-encryption-algorithm differs from be present when MSG1.content-encryption algorithm differs from
MSG2.key-encryption-algorithm, in which case it MUST be present. MSG2.key-encryption algorithm, in which case it MUST be present.
Implementations that recognize this attribute, but do not support Implementations that recognize this attribute, but do not support the
the functionality SHOULD ignore the attribute. functionality SHOULD ignore the attribute.
Ignoring attributes as discussed above, will lead to decryption Ignoring attributes as discussed above, will lead to decryption
failures. CMS implementations SHOULD be able to signal the failures. CMS implementations SHOULD be able to signal the
particular reason for this failure to the calling application. particular reason for this failure to the calling application.
6. Security Considerations 6. Security Considerations
Encryption does not provide authentication, for example, if the Encryption does not provide authentication, for example, if the
encryptedContent is essentially random then recipients MUST NOT encryptedContent is essentially random then recipients MUST NOT
assume that "knowing" a CEKReference value proves anything - anyone assume that "knowing" a CEKReference value proves anything - anyone
could have created the EnvelopedData. This is relevant both for could have created the EnvelopedData. This is relevant both for
security (the recovered plaintext should not be entirely random) and security (the recovered plaintext should not be entirely random) and
for avoiding denial of service (the recipient MUST NOT assume that for avoiding denial of service (the recipient MUST NOT assume that
using the right CEKReference means that message originator is using the right CEKReference means that message originator is
genuine). genuine).
Similarly, using the correct CEKReference does not mean that a Similarly, using the correct CEKReference does not mean that a
message has not been replayed or inserted, and recipients MUST NOT message has not been replayed or inserted, and recipients MUST NOT
assume that replay has been avoided. assume that replay has been avoided.
The maxDecrypts field presents a potential denial-of-service attack The maxDecrypts field presents a potential denial-of-service attack
if a very large value is included by an originator in an attempt to if a very large value is included by an originator in an attempt to
get a recipient to consume memory by storing the referenced CEKs for get a recipient to consume memory by storing the referenced CEKs for
a long period or if the originator never sends the indicated number a long period or if the originator never sends the indicated number
of ciphertexts. Recipients SHOULD therefore drop referenced CEKs of ciphertexts. Recipients SHOULD therefore drop referenced CEKs
where the maxDecrypts value is too large (according to local where the maxDecrypts value is too large (according to local
configuration) or the referenced CEK has been held for too long a configuration) or the referenced CEK has been held for too long a
period. period.
Suppose MSG1 is sent to a set S1 of users. In the case where MSG2 is Suppose MSG1 is sent to a set S1 of users. In the case where MSG2 is
sent to only a subset of users in S1, all users from S1 will still sent to only a subset of users in S1, all users from S1 will still be
be able to decrypt MSG2 (since MSG2.KEK is computed only from able to decrypt MSG2 (since MSG2.KEK is computed only from MSG1.CEK).
MSG1.CEK). Implementers should be aware that in such cases, all Implementers should be aware that in such cases, all members of the
members of the original set of recipients (S1) can access the original set of recipients (S1) can access the plaintext of MSG2 and
plaintext of MSG2 and subsequent messages. subsequent messages.
The reason for the byte reversal is as follows: without the byte The reason for the byte reversal is as follows: without the byte
reversal, an attacker knowing some of MSG1.plaintext (a prefix in a reversal, an attacker knowing some of MSG1.plaintext (a prefix in a
field for instance) can use the corresponding ciphertext block as field for instance) can use the corresponding ciphertext block as the
the next encrypted CEK, i.e. as MSG2.KEKRecipientInfo.encryptedKey. next encrypted CEK, i.e., as MSG2.KEKRecipientInfo.encryptedKey. Now
Now the attacker knows the next CEK. This attacks something this the attacker knows the next CEK. This attacks something this note is
note is not claiming to protect (origin authentication), but is not claiming to protect (origin authentication), but is easily
easily avoided using the byte reversal. Byte-reversal was chosen avoided using the byte reversal. Byte-reversal was chosen over bit-
over bit-reversal since bit-reversal would cause parity bits from reversal since bit-reversal would cause parity bits from MSG1.CEK to
MSG1.CEK to be used as keying bits for MSG2.KEK for DES-based be used as keying bits for MSG2.KEK for DES-based algorithms. Note
algorithms. Note that byte reversal would similarly affect parity if that byte reversal would similarly affect parity if parity checks
parity checks spanned more than one octet, however no well-known spanned more than one octet, however no well-known algorithms operate
algorithms operate in this way. in this way.
Implementations should be very careful with this scheme if Implementations should be very careful with this scheme if MSG[n].KEK
MSG[n].KEK is used to derive MSG[n].CEK, e.g. if MSG[n].CEK were the is used to derive MSG[n].CEK, e.g., if MSG[n].CEK were the byte-
byte-reversal of MSG[n].KEK, then this scheme could result in a reversal of MSG[n].KEK, then this scheme could result in a fixed key
fixed key being unexpectedly used. being unexpectedly used.
7. References 7. References
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630. [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June
[CMS-MSG] Ramsdell, B. "S/MIME Version 3 Message Specification", 1999.
RFC 2633.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, September 2000.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", RFC 2026, BCP 9, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119.
Author's Addresses [CMS-MSG] Ramsdell, B. "S/MIME Version 3 Message Specification", RFC
2633, June 1999.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, September 2000.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Stephen Farrell, Stephen Farrell,
Baltimore Technologies, Baltimore Technologies,
39 Parkgate Street, 39 Parkgate Street,
Dublin 8 Dublin 8
IRELAND IRELAND
tel: +353-1-881-6000 Phone: +353-1-881-6000
email: stephen.farrell@baltimore.ie EMail: stephen.farrell@baltimore.ie
Sean Turner Sean Turner
IECA, Inc. IECA, Inc.
9010 Edgepark Road 9010 Edgepark Road
Vienna, VA 22182 Vienna, VA 22182
USA USA
tel: +1.703.628.3180 Phone: +1.703.628.3180
email: turners@ieca.com EMail: turners@ieca.com
Full Copyright Statement
Copyright (C) The Internet Society (date). All Rights Reserved.
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. In addition,
the ASN.1 module presented in Appendix B may be used in whole or in
part without inclusion of the copyright notice. 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 shall 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 is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS 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.
Appendix A: ASN.1 Module Appendix A: ASN.1 Module
SMIMERcek SMIMERcek
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) rcek(13) } smime(16) modules(0) rcek(13) }
-- This module contains the definitions of the attributes
-- used for re-using the content encryption key from a
-- message in further messages.
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
IMPORTS
AlgorithmIdentifier FROM -- This module contains the definitions of the attributes
AuthenticationFramework { joint-iso-itu-t ds(5) -- used for re-using the content encryption key from a
module(1) authenticationFramework(7) 3 } ; -- message in further messages.
-- [RFC2898] uses 1993 ASN.1 to define PBKDF2-params. Since DEFINITIONS IMPLICIT TAGS ::=
-- this specification only uses 1988 ASN.1, the definition is
-- repeated here for completeness.
-- The DEFAULT prf field value, MUST be used for this BEGIN
-- specification -- EXPORTS ALL --
digestAlgorithm OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) 2}
id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7}
-- [RFC2898] defines PBKDF2-params using 1993 ASN.1, which IMPORTS
-- results in the same encoding as produced by the definition
-- below. See [RFC2898] for that definition.
PBKDF2-params ::= SEQUENCE { AlgorithmIdentifier FROM
salt CHOICE { AuthenticationFramework { joint-iso-itu-t ds(5)
specified OCTET STRING, -- MUST BE USED module(1) authenticationFramework(7) 3 } ;
otherSource AlgorithmIdentifier -- DO NOT USE THIS FIELD
},
iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL
}
-- id-aa is the arc with all new authenticated and -- [RFC2898] uses 1993 ASN.1 to define PBKDF2-params. Since
-- unauthenticated attributes produced the by S/MIME -- this specification only uses 1988 ASN.1, the definition is
-- Working Group. It is also defined in [CMS-MSG] -- repeated here for completeness.
id-aa OBJECT IDENTIFIER ::= -- The DEFAULT prf field value, MUST be used for this
{iso(1) member-body(2) usa(840) rsadsi(113549) -- specification
pkcs(1) pkcs-9(9) smime(16) attributes(2)} digestAlgorithm OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) 2}
id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7}
-- This attribute contains what will be the key identifier -- [RFC2898] defines PBKDF2-params using 1993 ASN.1, which
-- for subsequent messages -- results in the same encoding as produced by the definition
id-aa-CEKReference OBJECT IDENTIFIER ::= { id-aa 30 } -- below. See [RFC2898] for that definition.
CEKReference ::= OCTET STRING
-- This attribute contains a "hint" to the recipient PBKDF2-params ::= SEQUENCE {
-- indicating how many times the originator will use salt CHOICE {
-- the re-used CEK specified OCTET STRING, -- MUST BE USED
id-aa-CEKMaxDecrypts OBJECT IDENTIFIER ::= { id-aa 31 } otherSource AlgorithmIdentifier -- DO NOT USE THIS FIELD
CEKMaxDecrypts ::= INTEGER },
iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL
}
-- This attribute specifies the key derivation function -- id-aa is the arc with all new authenticated and
-- to be used when the default byte reversal operation cannot -- unauthenticated attributes produced the by S/MIME
-- be used. -- Working Group. It is also defined in [CMS-MSG]
id-aa OBJECT IDENTIFIER ::=
{iso(1) member-body(2) usa(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) attributes(2)}
id-aa-KEKDerivationAlg OBJECT IDENTIFIER ::= { id-aa 32 } -- This attribute contains what will be the key identifier
KEKDerivationAlgorithm ::= SEQUENCE { -- for subsequent messages
kekAlg AlgorithmIdentifier, id-aa-CEKReference OBJECT IDENTIFIER ::= { id-aa 30 }
pbkdf2Param PBKDF2-params } CEKReference ::= OCTET STRING
END -- This attribute contains a "hint" to the recipient
-- indicating how many times the originator will use
-- the re-used CEK
id-aa-CEKMaxDecrypts OBJECT IDENTIFIER ::= { id-aa 31 }
CEKMaxDecrypts ::= INTEGER
Appendix B: Revision History -- This attribute specifies the key derivation function
-- to be used when the default byte reversal operation cannot
-- be used.
Note to RFC editor: Please delete this section. id-aa-KEKDerivationAlg OBJECT IDENTIFIER ::= { id-aa 32 }
KEKDerivationAlgorithm ::= SEQUENCE {
kekAlg AlgorithmIdentifier,
pbkdf2Param PBKDF2-params }
Changes from -00 to -01: END
- Removed error flag attribute, since this is the responsibility of Full Copyright Statement
a consuming protocol
- Change the key derivation from home-grown to use pkcs#5 scheme
- Added compilable ASN.1 module
Changes from -01 to -02: Copyright (C) The Internet Society (2001). All Rights Reserved.
- Changed default KDF from bit to byte reversal to avoid parity-bit This document and translations of it may be copied and furnished to
problems others, and derivative works that comment on or otherwise explain it
- Added allocated OIDs for module and attributes or assist in its implementation may be prepared, copied, published
- Added more justification text to section 2 and distributed, in whole or in part, without restriction of any
- Added conformance text (new section 5) kind, provided that the above copyright notice and this paragraph are
- Added security consideration about subset of recipients included on all such copies and derivative works. However, this
- Added security consideration describing reason for byte reversal document itself may not be modified in any way, such as by removing
- Changed from unidirectional since Diameter may need bi-directional the copyright notice or references to the Internet Society or other
- Copied kdf params stuff from rfc2898 since it uses '93 ASN.1 Internet organizations, except as needed for the purpose of
- Changed so that max decrypts=1, implies that one more message can developing Internet standards in which case the procedures for
re-use the CEK (used to be silly where a value of 1 meant no more) copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
Changes from -02 to -03 The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
- Removed extra comma from ASN.1 module This document and the information contained herein is provided on an
- Reworded section 4, para 6 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Changes from -03 to -04 Acknowledgement
- Added a clarification at end section 3 and a related security Funding for the RFC Editor function is currently provided by the
consideration. Internet Society.
 End of changes. 75 change blocks. 
267 lines changed or deleted 230 lines changed or added

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