RFC 8351

The PKCS #8 EncryptedPrivateKeyInfo Media Type

📅 published June 2018, from ietf

RFC 8351: The PKCS #8 EncryptedPrivateKeyInfo Media Type 🎀

okay bestie, let's talk about this one ✨ It's an Informational doc from Sean Leonard at Penango, Inc., published as an Independent Submission in June 2018 (ISSN 2070-1721). It's not on the Standards Track, so it's not an Internet Standard, and it doesn't list any RFCs it obsoletes or updates 💅

The whole point is to register a new media type, application/pkcs8-encrypted, for a single encrypted private key in PKCS #8 format. Iconic, honestly 🦋

Status and copyright stuff is below, so you can skip it if you want 🙈

Abstract

okay so this doc registers application/pkcs8-encrypted as the media type for the EncryptedPrivateKeyInfo type of PKCS #8 💖 Each instance carries one encrypted private key, BER-encoded as a single EncryptedPrivateKeyInfo value 🔐

Status of This Memo

ngl this part is pretty formal 💀 The short version: this document is not an Internet Standards Track spec, it's just published for information 🌸

It's a contribution to the RFC Series, separate from any other RFC stream. The RFC Editor chose to publish it at their discretion and doesn't say whether it's good for implementing or deploying 🫶 Docs the RFC Editor approves aren't candidates for any level of Internet Standard. See Section 2 of RFC 7841 for that.

For the current status, any errata, and how to give feedback, check https://www.rfc-editor.org/info/rfc8351 ✨

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) as they stood on the publication date. Please actually read these, because they spell out your rights and restrictions for this document 📜

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

so the private key gets encrypted with some encryption algorithm 🔑 That could be a password-based encryption scheme, the kind defined in PKCS #5: Password-Based Cryptography Specification Version 2.1, which is published as [RFC2898] and updated by [RFC8018] 💜

This doc registers the application/pkcs8-encrypted media type for the EncryptedPrivateKeyInfo type of PKCS #8. The original description was in [RFC5208], which got 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

Here's the registration template, bestie 🎀

Type name: application

Subtype name: pkcs8-encrypted

Required parameters: None. 🌸

Optional parameters:

password-mapping: okay, this is the big one 👑 The private key is encrypted with an encryption algorithm, which could be a password-based scheme as defined in PKCS #5 ([RFC2898] and [RFC8018]). These algorithms take a password as input. In this context, a "password" is a secret text value (see Section 3 of [RFC2898] and [RFC8018]), but for the math, the algorithm actually works on an octet string (see Section 2 of [RFC2898] and [RFC8018]) 🤓 So there has to be some mapping between the text value, which might be what the user typed in, and that octet string 🦋

Section 3 of [RFC2898] (which [RFC8018] replaced) says applications "follow some common text encoding rules" and then offers ASCII and UTF-8 as options, without actually recommending either one 💅

Now, lots of modern apps handle Unicode, like UTF-8 and UTF-16 🌈 But interchange still matters, because you'll run into private key files that were encrypted with passwords in other encodings. So this parameter names the charset (see Section 1.3 of [RFC2978]) that a recipient should try first, working in "reverse", when mapping a sequence of characters into an octet string ✨ Heads up: this parameter isn't cryptographically protected, so recipients can't treat it as the only possible mapping 🙈

It works a lot like the charset parameter on text/plain, except it only applies to the user's password input (the text value) 💖 There's no default value.

The special values below all start with "*" so they can't be confused with registered charsets 💅

*pkcs12      UTF-16LE with U+0000 NULL terminator: PKCS #12
             style, see [RFC7292].

*precis      Preparation, Enforcement, and Comparison of
             Internationalized Strings (PRECIS) password
             profile, i.e., OpaqueString from Section 4 of
             [RFC7613], which was obsoleted by [RFC8265]: always
             UTF-8 in Normalization Form C (NFC).

*precis-XXX  Any profile from the IANA "PRECIS Profiles"
             registry where "XXX" is replaced by the profile
             name as shown in the registry.

*hex         hexadecimal input: the input is mapped to 0-9, A-F,
             and then converted directly to octets.  If there
             are an odd number of hex digits, either the final
             digit 0 is appended or an error condition is
             raised.  Compare with Annex M.4 of
             [IEEE.802.11-2012].

*dtmf        The characters "0"-"9", "A"-"D", "*", and "#",
             which map to their corresponding ASCII codes.
             "A"-"D" map to the uppercase range 0x41 - 0x44.
             (This is to support restricted-input devices, i.e.,
             telephones and telephone-like equipment.)  User
             input outside of these values is either ignored or
             an error condition is raised.

Quick breakdown, because these are a lot 🫶

  • *pkcs12 is UTF-16LE with a U+0000 NULL terminator, the PKCS #12 style, which you can read about in [RFC7292] 💜
  • *precis is the PRECIS password profile, which is OpaqueString from Section 4 of [RFC7613]. That one got obsoleted by [RFC8265], and it's always UTF-8 in Normalization Form C (NFC) 🌸
  • *precis-XXX covers any profile in the IANA "PRECIS Profiles" registry. You just swap "XXX" for the profile name as it appears in the registry ✨
  • *hex is hexadecimal input. Each character gets mapped to 0-9 or A-F, then turned directly into octets. If you've got an odd number of hex digits, either a final digit 0 gets appended or an error gets raised. For a comparison, check out Annex M.4 of [IEEE.802.11-2012] 🦋
  • *dtmf is for the characters "0"-"9", "A"-"D", "*", and "#", which map to their ASCII codes. "A"-"D" land in the uppercase range 0x41 - 0x44. It exists for restricted-input devices, like telephones and phone-like equipment 📞 Any input outside those values is either ignored or raises an error 🙈

Anything else in this parameter is a charset from the IANA "Character Sets" registry [CHARREG] 🎀

And the parameter is case insensitive, so UTF-8 and utf-8 are the same thing 💅

More of the registration template, plus the IANA, Security, and References sections, is coming in part 2 🌈

5. Normative References ✨

okay bestie, these are the docs this spec literally cannot live without 💅 (normative = you NEED them, no cap) 📚

Author's Address 🫶

Here's where the author lives, in case you want to reach out! 💌

Sean Leonard
Penango, Inc.
5900 Wilshire Blvd
Ste 2600
Los Angeles, CA  90036
United States of America

Email: dev+ietf@seantek.com
URI:   http://www.penango.com/

and that's the whole RFC, bestie!! 🌈✨💖

📦 where this page comes from