RFC 3185 (rfc3185) - Page 2 of 10

Reuse of CMS Content Encryption Keys

RFC 3185          Reuse of CMS Content Encryption Keys      October 2001


1. Introduction

   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 MSG1) to derive the key-encryption key (KEK) for a
   later message, (MSG2), 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 [RFC 2119].

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 protocol 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".

   -  This specification is not suitable for general group key
      management.








Farrell & Turner            Standards Track