Reuse of CMS Content Encryption Keys (RFC3185)

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 spe...