Algorithms for Asymmetric Key Package Content Type
RFC 5959
| Document | Type |
RFC - Proposed Standard
(August 2010; No errata)
Updated by RFC 6162
Was draft-turner-asymmetrickeyformat-algs (individual in gen area)
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Reviews | |||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 5959 (Proposed Standard) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Tim Polk | ||
| Send notices to | cwallace@cygnacom.com | ||
Internet Engineering Task Force (IETF) S. Turner
Request for Comments: 5959 IECA
Category: Standards Track August 2010
ISSN: 2070-1721
Algorithms for Asymmetric Key Package Content Type
Abstract
This document describes the conventions for using several
cryptographic algorithms with the EncryptedPrivateKeyInfo structure,
as defined in RFC 5958. It also includes conventions necessary to
protect the AsymmetricKeyPackage content type with SignedData,
EnvelopedData, EncryptedData, AuthenticatedData, 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/rfc5959.
Copyright Notice
Copyright (c) 2010 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 5959 Algorithms for Asymmetric Key Packages August 2010
1. Introduction
This document describes the conventions for using several
cryptographic algorithms with the EncryptedPrivateKeyInfo structure
[RFC5958]. The EncryptedPrivateKeyInfo is used by [P12] to encrypt
PrivateKeyInfo [RFC5958]. It is similar to EncryptedData [RFC5652]
in that it has no recipients, no originators, and no content
encryption keys and requires keys to be managed by other means.
This document also includes conventions necessary to protect the
AsymmetricKeyPackage content type [RFC5958] with Cryptographic
Message Syntax (CMS) protecting content types: SignedData [RFC5652],
EnvelopedData [RFC5652], EncryptedData [RFC5652], AuthenticatedData
[RFC5652], and AuthEnvelopedData [RFC5083]. Implementations of
AsymmetricKeyPackage do not require support for any CMS protecting
content type; however, if the AsymmetricKeyPackage is CMS protected
it is RECOMMENDED that conventions defined herein be followed.
This document does not define any new algorithms instead it refers to
previously defined algorithms.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. EncryptedPrivateKeyInfo
The de facto standard used to encrypt the PrivateKeyInfo structure,
which is subsequently placed in the EncryptedPrivateKeyInfo
encryptedData field, is Password Based Encryption (PBE) based on PKCS
#5 [RFC2898] and PKCS #12 [P12]. The major difference between PKCS
#5 and PKCS #12 is the supported encoding for the password: ASCII for
PKCS #5 and Unicode for PKCS #12, encoded as specified in Section B.1
of [P12]. [RFC2898] specifies two PBE Schemes (PBES) 1 and 2;
[RFC2898] recommends PBES2 for new specification. PBES2 with a key
derivation algorithm of PBKDF2 using HMAC with SHA-256 [RFC5754] and
an encryption algorithm of AES Key Wrap with Padding as defined in
[RFC5649] MUST be supported. AES-256 Key Wrap with Padding [RFC5649]
MAY also be supported as an encryption algorithm.
3. AsymmetricKeyPackage
As noted in Asymmetric Key Packages [RFC5958], CMS can be used to
protect the AsymmetricKeyPackage. The following provides guidance
for SignedData [RFC5652], EnvelopedData [RFC5652], EncryptedData
Turner Standards Track [Page 2]
RFC 5959 Algorithms for Asymmetric Key Packages August 2010
Show full document text