The PKCS #8 EncryptedPrivateKeyInfo Media Type
RFC 8351

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00
• 01
• 02
• 03

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: