Reuse of CMS Content Encryption Keys
RFC 3185

Document Type RFC - Proposed Standard (October 2001; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3185 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         S. Farrell
Request for Comments: 3185                        Baltimore Technologies
Category: Standards Track                                      S. Turner
                                                                    IECA
                                                            October 2001

                  Reuse of CMS Content Encryption Keys

Status of this Memo

   This document specifies an Internet standards track protocol for the
   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.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

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

Table Of Contents

   1. Introduction...................................................  2
   2. Applicability..................................................  2
   3. How to do it...................................................  3
   4. Using different CEK and KEK algorithms.........................  4
   5. Conformance....................................................  5
   6. Security Considerations........................................  5
   7. References.....................................................  6
   Authors' Addresses................................................  6
   Appendix A: ASN.1 Module..........................................  7
   Full Copyright Statement.......................................... 10

Farrell & Turner            Standards Track                     [Page 1]
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 [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 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                     [Page 2]
RFC 3185          Reuse of CMS Content Encryption Keys      October 2001

   -  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
Show full document text