The PKCS #8 EncryptedPrivateKeyInfo Media Type
RFC 8351
Document | Type |
RFC - Informational
(June 2018; No errata)
Was draft-seantek-pkcs8-encrypted (individual)
|
|
---|---|---|---|
Author | Sean Leonard | ||
Last updated | 2018-06-26 | ||
Stream | ISE | ||
Formats | plain text html pdf htmlized bibtex | ||
IETF conflict review | conflict-review-seantek-pkcs8-encrypted | ||
Stream | ISE state | Published RFC | |
Consensus Boilerplate | Unknown | ||
Document shepherd | Adrian Farrel | ||
Shepherd write-up | Show (last changed 2017-11-14) | ||
IESG | IESG state | RFC 8351 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | Nevil Brownlee <rfc-ise@rfc-editor.org> | ||
IANA | IANA review state | IANA OK - Actions Needed | |
IANA action state | RFC-Ed-Ack |
Independent Submission S. Leonard Request for Comments: 8351 Penango, Inc. Category: Informational June 2018 ISSN: 2070-1721 The PKCS #8 EncryptedPrivateKeyInfo Media Type Abstract This document registers the application/pkcs8-encrypted media type for the EncryptedPrivateKeyInfo type of PKCS #8. An instance of this media type carries a single encrypted private key, BER-encoded as a single EncryptedPrivateKeyInfo value. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8351. Copyright Notice Copyright (c) 2018 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 (https://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. Leonard Informational [Page 1] RFC 8351 PKCS #8 EncryptedPrivateKeyInfo Media Type June 2018 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Registration Application . . . . . . . . . . . . . . . . . . 2 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. Normative References . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction The private key is encrypted with an encryption algorithm, which could be a password-based encryption scheme as that term is used in PKCS #5: Password-Based Cryptography Specification Version 2.1 as published in [RFC2898] and updated by [RFC8018]. This document registers the application/pkcs8-encrypted media type for the EncryptedPrivateKeyInfo type of PKCS #8 (as originally described in [RFC5208], which was obsoleted by [RFC5958]). An instance of this media type carries a single encrypted private key [RFC5958] BER- encoded as a single EncryptedPrivateKeyInfo value. 2. Registration Application Type name: application Subtype name: pkcs8-encrypted Required parameters: None. Optional parameters: password-mapping: The private key is encrypted with an encryption algorithm, which could be a password-based encryption scheme as that term is used in PKCS #5 ([RFC2898] and [RFC8018]). Such algorithms take a password as input. A "password" is a secret text value (see Section 3 of [RFC2898] and [RFC8018]), but for algorithmic purposes the term "password" refers to an octet string (see Section 2 of [RFC2898] and [RFC8018]). Therefore, there must be some mapping between the text value (which might be user input) and the octet string. Section 3 of [RFC2898] (which was replaced by [RFC8018]) recommends "that applications follow some common text encoding rules"; it then offers, but does not recommend, ASCII and UTF-8. Leonard Informational [Page 2] RFC 8351 PKCS #8 EncryptedPrivateKeyInfo Media Type June 2018 While many modern applications support Unicode and Unicode-based encodings such as UTF-8 and UTF-16, interchange is still needed with private key artifacts that are encrypted with passwords in other encodings. Therefore, this parameter specifies the charset (see Section 1.3 of [RFC2978]) that a recipient should attempt first, in "reverse", when mapping from a sequence of characters to an octet string. This parameter is not cryptographically protected, so recipients cannot rely on it as the exclusive mapping possibility. This parameter has similar semantics to the charset parameter from text/plain, except that it only applies to the user's input (text value) of a password. There is no default value. The following special values, which all begin with "*" to distinguish them from registered charsets, are defined:Show full document text