[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 rfc3185                                        
INTERNET-DRAFT                                              S. Farrell
Expires in six months                           Baltimore Technologies
                                                             S. Turner
                                                        September 2000

                   Reuse of CMS Content Encryption Keys

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of [RFC2026].

   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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at


   This note describes a way to include a key identifier in a CMS
   enveloped data structure, so that the content encryption key can be
   re-used for further enveloped data packets.

Table Of Contents

   Status of this Memo.............................................1
   Table Of Contents...............................................1
   1. Introduction.................................................2
   2. Applicability................................................2
   3. How to do it.................................................3
   4. Using different CEK and KEK algorithms.......................4
   5. Security Considerations......................................5
   6. References...................................................6
   Author's Addresses..............................................6
   Full Copyright Statement........................................6

Farrell & Turner                                              [Page 1]

INTERNET-DRAFT                                          September 2000

1. Introduction

   <<Editorial comments are in angle-brackets, like this.>>

   CMS [CMS] specifies EnvelopedData.  EnvelopedData supports data
   encryption using either symmetric or asymmetric key management
   techniques. Since asymmetric key establishment is relatively
   expensive, it is desirable in some environments to re-use a shared
   content-encryption key established using asymmetric mechanisms for
   encryption operations in subsequent messages.

   The basic idea here is to reuse the content encryption key (CEK)
   from a message (say message 1) to derive the key encryption key
   (KEK) for a later message, (message 2), by including a reference
   value for the CEK in message 1, and that same value as the
   KEKIdentifier for message 2. The CEK from message 1 is called the
   "referenced CEK".

   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
   in this document are to be interpreted as described in [RFC2119].

2. Applicability

   This specification is intended to be used to provide more efficient
   selective field confidentiality between communicating peers, in
   particular in the cases where:

   - The originator is a client that wishes to send a number of fields
     to a server (the recipient) in a single transaction, where the
     referenced CEK is used for the separate encryption of each field.

   - The originator and recipient are servers that communicate very
     frequently and use this specification purely for efficiency.

   This specification is not intended to be applicable in all cases. It
   is suited for use where:

   - Its use is further scoped: that is, this specification doesn't
     define a system but merely a trick that can be used in a larger
     context and additional specification will be needed for each such
     case. In particular, in order to use this specification, it is
     REQUIRED to define the originators' and recipients' behavior where
     a referenced CEK has been "lost".

   - Key encryption is "unidirectional": that is, the referenced CEK is
     only used by the originator for encryption and the recipient for
     decryption, recipients must not expect originators to be able to
     decrypt using (anything derived from) the referenced CEK. This
     means that the referenced CEK MUST NOT be considered to be a
     shared secret between many parties (i.e. this specification is not
     sufficient for group keying schemes). This also means that
     originators may have discarded the referenced CEK by the time the
     recipient receives the first message containing the reference.

Farrell & Turner                                              [Page 2]

INTERNET-DRAFT                                          September 2000

     Recipients MUST NOT use the referenced CEK when replying to the
     originator. <<Is this too restrictive?>>

   - The underlying cryptographic API is suitable: it is very likely
     that any cryptographic API that completely "hides" the bits of
     cryptographic keys from the CMS layer will prevent reuse of a
     referenced CEK (since they won't have a primitive that allows
     MSG1.CEK to be transformed to MSG2.KEK).

   - The algorithms for content and key encryption have compatible key
     values and strengths, that is, if MSG1.contentEncryptionAlgorithm
     is a 40bit cipher and MSG2.keyEncryptionAlgorithm requires 168
     bits of keying material, then this specification SHOULD NOT be

   In particular, this specification is not intended to be a general
   specification for group key management.

3. How to do it

   In order to reference the content-encryption key (CEK) used in an
   EnvelopedData (call this MSG1) a key identifier can be included in
   the unprotectedAttrs field of MSG1. This key can then be used to
   derive the key-encryption key (KEK) for other instances of
   EnvelopedData (say MSG2) or for other purposes. If the CEK from MSG1
   is to be used to dervie the KEK for MSG2 then MSG1 MUST contain an
   unprotectedAttrs Attribute of type id-cek-reference with a single
   value using the CEKReference syntax.

   MSG2.KEK is to be derived by reversing the bits of MSG1.CEK. The bit
   reversal is to avoid an attack where the attacker has a known
   plaintext and the related ciphertext (encrypted with MSG1.CEK) that
   (otherwise) could be directly used as a MSG2.KEK.

   The application MUST ensure that the relevant algorithms are
   compatible. That is, a CEKReference attribute alone can only be used
   where the content-encryption algorithm from MSG1 employs the same
   type of symmetric key as the key-encryption algorithm from MSG2.


   1) There is nothing to prevent inclusion of a CEKReference attribute
      in MSG2 as well as in MSG1. That is, an originator could "roll"
      the referenced CEK with every message.
   2) The CEKReference attribute can occur in any of the choices for
      RecipientInfo: ktri, kari or kekri. Implementors MUST NOT assume
      that CEKReference can only occur where ktri or kari is used.

   id-cek-reference ::= OBJECT IDENTIFIER { TBD }
   CEKReference ::= OCTET STRING

Farrell & Turner                                              [Page 3]

INTERNET-DRAFT                                          September 2000

   In order to allow the originator of MSG1 to indicate the "lifetime"
   of the CEK, the originator MAY include a CEKMaxDecrypts attribute,
   also in the unprotectedAttrs field of EnvelopedData. This attribute
   has an INTEGER syntax (the value MUST be >=1), and indicates to the
   recipient the maximum number of messages (including this one) that
   will use the referenced CEK. This Attribute MUST only be sent when a
   CEKReference attribute is also included.

   The recipient SHOULD maintain the CEKReference information
   (minimally the key identifier and the CEK value) while less than
   maxDecrypt messages have been successfully received. Recipients
   SHOULD delete the CEKReference information after some locally
   configured period.

   id-cek-maxDecrypts ::= OBJECT IDENTIFIER { TBD }
   CEKMaxDecrypts ::= INTEGER

   <<The unknown reference attribute is probably not needed, since the
   consuming application probably has to do the signalling at the
   application layer and not the "CMS" layer, but if we did need
   it... Unless there's a specific reason, this will disappear in the
   next draft.>>
   When a recipient receives a message that contains a CEKReference
   that it cannot use (for whatever reason), then the recipient MAY
   respond to the originator with a message containing an
   UnknownReference attribute. This attribute SHOULD be in either
   signedAttrs or authenticatedAttrs, but MAY be in unsignedAttrs in an
   otherwise empty SignedData.

   id-kek-unknownReference::= OBJECT IDENTIFIER { TBD }
   UnknownReference ::= OCTET STRING

   The value of this MUST be the KEKIdentifier from the message that
   caused the problem.

4. Using different CEK and KEK algorithms

   Where MSG1.content-encryption algorithm and MSG2.key-encryption
   algorithm are the same then the MSG2.KEK is the bit-reversal of
   MSG1.CEK. However, in general, these algorithms MAY differ, e.g.
   requiring different key lengths. This section specifies a generic
   way to derive MSG2.KEK for such cases.

   Implementations MAY include this functionality.

   In this case the originator MUST include a KEKDerivationAlgorithm
   attribute in MSG1, which indicates how to derive MSG2.KEK from
   MSG1.CEK. This attribute has the following syntax:

   id-kek-derivation-algorithm ::= OBJECT IDENTIFIER { TBD }
   KEKDerivationAlgorithm ::= SEQUENCE {
        algorithm       OBJECT IDENTIFIER,
        iv              OCTET STRING OPTIONAL,

Farrell & Turner                                              [Page 4]

INTERNET-DRAFT                                          September 2000

        padding         OCTET STRING OPTIONAL,
        kekAlg          AlgorithmIdentifier }

   <<It's not clear that this specification needs to define its own key
   derivation scheme for this case (since itÆs a MAY, not a SHOULD or
   MUST). If we have to, it would certainly be better if we could
   reference an existing derivation algorithm. In other words, this
   section is likely to change, a lot.>>

   In order to derive MSG2.KEK from MSG1.CEK the following algorithm is

   1. Randomly pick an IV if necessary and some padding bytes
   2. DER encode the kekAlg value, producing kek-alg-d. kek-alg-d does
       include the full DER encoding, that is, it begins with the '30'H
       from the ASN.1 SEQUENCE.
   3. Catenate the following values to produce CEK-input:
       CEK-input = "padding-bytes||CEK||CEKReference||key-alg-d"
       Note: the padding and CEKReference are both transmitted in the
       KEKDerivationAlgorithm structure as ASN.1 OCTET STRINGS, but
       CEK-input MUST NOT include OCTET STRING tags or lengths for
   4. Encrypt CEK-input using MSG1.content-encryption algorithm and
       the CEK as key, with the IV generated in step 1, (if an IV is
       necessary), giving KEK-input.
   5. The KEK is the rightmost bits of KEK-input, as required by

5. Security Considerations

   Encryption does not provide authentication, for example, if the
   encryptedContent is essentially random then recipients MUST NOT
   assume that "knowing" a CEKReference value proves anything - anyone
   could have created the EnvelopedData. This is relevant both for
   security (the recovered plaintext should not be entirely random) and
   for avoiding denial of service (the recipient MUST NOT assume that
   using the right CEKReference means that message originator is

   Similarly, using the correct CEKReference does not mean that a
   message has not been replayed or inserted, and recipients MUST NOT
   assume that replay has been avoided.

   The maxDecrypts field presents a potential denial-of-service attack
   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
   a long period or if the originator never sends the indicated number
   of ciphertexts. Recipients SHOULD therefore drop referenced CEKs
   where the maxDecrypts value is too large (according to local
   configuration) or the referenced CEK has been held for too long a

Farrell & Turner                                              [Page 5]

INTERNET-DRAFT                                          September 2000

   <<More TBS no doubt.>>

6. References

  [CMS]       Housley, R., "Cryptographic Message Syntax", RFC 2630.
  [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

   Stephen Farrell,
   Baltimore Technologies,
   61/62 Fitzwilliam Lane,
   Dublin 2,

   tel: +353-1-647-3000
   email: stephen.farrell@baltimore.ie

   Sean Turner
   IECA, Inc.
   9010 Edgepark Road
   Vienna, VA 22182

   tel: +1.703.628.3180
   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

   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

Farrell & Turner                                              [Page 6]

INTERNET-DRAFT                                          September 2000


Farrell & Turner                                              [Page 7]