Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type
RFC 5083

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 06

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 is