Algorithms for Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types
RFC 7192
| Document | Type |
RFC - Proposed Standard
(April 2014; No errata)
Was draft-turner-ct-keypackage-receipt-n-error-algs (individual in sec area)
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Reviews | |||
| Stream | WG state | (None) | |
| Document shepherd | Carl Wallace | ||
| Shepherd write-up | Show (last changed 2013-10-30) | ||
| IESG | IESG state | RFC 7192 (Proposed Standard) | |
| Consensus Boilerplate | Yes | ||
| Telechat date | |||
| Responsible AD | Stephen Farrell | ||
| Send notices to | (None) | ||
| IANA | IANA review state | IANA OK - No Actions Needed | |
| IANA action state | No IC | ||
Internet Engineering Task Force (IETF) S. Turner
Request for Comments: 7192 IECA
Category: Standards Track April 2014
ISSN: 2070-1721
Algorithms for Cryptographic Message Syntax (CMS)
Key Package Receipt and Error Content Types
Abstract
This document describes the conventions for using several
cryptographic algorithms with the Cryptographic Message Syntax (CMS)
key package receipt and error content types. Specifically, it
includes conventions necessary to implement SignedData,
EnvelopedData, EncryptedData, and AuthEnvelopedData.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7192.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Turner Standards Track [Page 1]
RFC 7192 Algs for CMS Key Package Rcpt Content Type April 2014
1. Introduction
This document describes the conventions for using several
cryptographic algorithms with the Cryptographic Message Syntax (CMS)
key package receipt and error content types [RFC7191]. Specifically,
it includes conventions necessary to implement SignedData [RFC5652],
EnvelopedData [RFC5652], EncryptedData [RFC5652], and
AuthEnvelopedData [RFC5083].
This document does not define any new algorithms; instead, it refers
to previously defined algorithms. In fact, the algorithm
requirements in this document are the same as those in [RFC5959],
[RFC6033], [RFC6160], [RFC6161], and [RFC6162] with the following
exceptions: the content-encryption algorithm is AES in Cipher Block
Chaining (CBC) mode as opposed to AES Key Wrap with Message Length
Indicator (MLI) and the key-wrap algorithm is AES Key Wrap as opposed
to AES Key Wrap with MLI. The rationale for the difference is that
the receipt and error content types are not keys; therefore, AES Key
Wrap with MLI is not appropriate for the content-encryption
algorithm. If an implementation is not using AES Key Wrap with MLI
as the content-encryption algorithm, then there's no need to keep the
key-wrap algorithm the same as the content encryption algorithm.
NOTE: [RFC7191] only requires that the key package receipt be signed.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
2. SignedData
If an implementation supports SignedData, then it MUST support the
signature scheme RSA [RFC3370] and SHOULD support the signature
schemes RSA Probabilistic Signature Scheme (RSASSA-PSS) [RFC4056] and
Digital Signature Algorithm (DSA) [RFC3370]. Additionally,
implementations MUST support the hash function SHA-256 [RFC5754] in
concert with these signature schemes, and they SHOULD support the
hash function SHA-1 [RFC3370]. Implementations can also choose the
to support Elliptic Curve Digital Signature Algorithm (ECDSA)
[RFC5753] and [RFC6090].
Turner Standards Track [Page 2]
RFC 7192 Algs for CMS Key Package Rcpt Content Type April 2014
3. EnvelopedData
If an implementation supports EnvelopedData, then it MUST implement
key transport and it MAY implement key agreement.
Show full document text