Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type
RFC 5083
| Document | Type |
RFC - Proposed Standard
(November 2007; No errata)
Updates RFC 3852
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html 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
Show full document text