Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type
RFC 5083
Document | Type |
RFC - Proposed Standard
(November 2007; No errata)
Updates RFC 3852
|
|
---|---|---|---|
Author | Russ Housley | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5083 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Tim Polk | ||
Send notices to | (None) |
Network Working Group R. Housley Request for Comments: 5083 Vigil Security Updates: 3852 November 2007 Category: Standards Track Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type 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. Abstract This document describes an additional content type for the Cryptographic Message Syntax (CMS). The authenticated-enveloped-data content type is intended for use with authenticated encryption modes. All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped-data content type. 1. Introduction This document describes an additional content type for the Cryptographic Message Syntax (CMS) [CMS]. The authenticated- enveloped-data content type is intended for use with authenticated encryption modes, where an arbitrary content is both authenticated and encrypted. Also, some associated data in the form of authenticated attributes can also be authenticated. All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped-data content type. The conventions for using the Advanced Encryption Standard-Counter with Cipher Block Chaining-Message Authentication Code (AES-CCM) and the AES-Galois/Counter Mode (GCM) authenticated encryption algorithms with the CMS authenticated-enveloped-data content type defined in this document can be found in [AESALGS]. The authenticated-enveloped-data content type, like all of the other CMS content types, employs ASN.1 [X.208-88], and it uses both the Basic Encoding Rules (BER) [X.209-88] and the Distinguished Encoding Rules (DER) [X.509-88]. Housley Standards Track [Page 1] RFC 5083 Authenticated-Enveloped-Data November 2007 1.1. Terminology In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in [STDWORDS]. 1.2. Version Numbers The major data structure (AuthEnvelopedData) includes a version number as the first item in the data structure. The version number is intended to avoid ASN.1 decode errors. Some implementations do not check the version number prior to attempting a decode, and then if a decode error occurs, the version number is checked as part of the error handling routine. This is a reasonable approach; it places error processing outside of the fast path. This approach is also forgiving when an incorrect version number is used by the sender. Whenever the structure is updated, a higher version number will be assigned. However, to ensure maximum interoperability, the higher version number is only used when the new syntax feature is employed. That is, the lowest version number that supports the generated syntax is used. 2. Authenticated-Enveloped-Data Content Type The authenticated-enveloped-data content type consists of an authenticated and encrypted content of any type and encrypted content-authenticated-encryption keys for one or more recipients. The combination of the authenticated and encrypted content and one encrypted content-authenticated-encryption key for a recipient is a "digital envelope" for that recipient. Any type of content can be enveloped for an arbitrary number of recipients using any of the supported key management techniques for each recipient. In addition, authenticated but not encrypted attributes may be provided by the originator. The typical application of the authenticated-enveloped-data content type will represent one or more recipients' digital envelopes on an encapsulated content. Authenticated-enveloped-data is constructed by the following steps: 1. A content-authenticated-encryption key for a particular content- authenticated-encryption algorithm is generated at random. Housley Standards Track [Page 2] RFC 5083 Authenticated-Enveloped-Data November 2007 2. The content-authenticated-encryption key is encrypted for each recipient. The details of this encryption depend on the key management algorithm used, but four general techniques are supported: Key Transport: the content-authenticated-encryption key isShow full document text