Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Reuse of CMS Content Encryption Keys (RFC3185)

IP.com Disclosure Number: IPCOM000005865D
Original Publication Date: 2001-Oct-01
Included in the Prior Art Database: 2001-Nov-13
Document File: 11 page(s) / 20K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

S. Farrell: AUTHOR [+2]

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.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 17% of the total text.

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