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 [RFC5652], AuthenticatedData [RFC5652], and AuthEnvelopedData [RFC5083]. 3.1. SignedData If an implementation supports SignedData, then it MUST support the signature scheme RSA [RFC3370] [RFC5754] and SHOULD support the signature schemes RSASSA-PSS [RFC4056] and DSA [RFC3370] [RFC5754]. Additionally, implementations MUST support in concert with theseShow full document text