PKCS #8 content types: PKCS #8: Private-Key Information Content Types
Gives private-key files two official identifiers so they can travel inside CMS messages.
Mandel, J., Housley, R., and S. Turner, "PKCS #8: Private-Key Information Content Types", RFC 9939, DOI 10.17487/RFC9939, February 2026, <https://www.rfc-editor.org/info/rfc9939>.
@misc{rfc9939,
series = {Request for Comments},
number = 9939,
howpublished = {RFC 9939},
publisher = {RFC Editor},
doi = {10.17487/RFC9939},
url = {https://www.rfc-editor.org/info/rfc9939},
author = {J. Mandel and R. Housley and S. Turner},
title = {{PKCS #8: Private-Key Information Content Types}},
pagetotal = 6,
year = 2026,
month = feb,
} RFC text
Contents
Internet Engineering Task Force (IETF) J. Mandel
Request for Comments: 9939 AKAYLA
Category: Standards Track R. Housley
ISSN: 2070-1721 Vigil Security
S. Turner
sn3rd
February 2026
PKCS #8: Private-Key Information Content Types
Abstract
This document defines PKCS #8 content types for use with
PrivateKeyInfo and EncryptedPrivateKeyInfo as specified in RFC 5958.
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 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/rfc9939.
Copyright Notice
Copyright (c) 2026 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. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents
1. Introduction
2. Private-Key Information Content Types
3. ASN.1 Module
4. Security Considerations
5. IANA Considerations
6. References
6.1. Normative References
6.2. Informative References
Acknowledgments
Authors' Addresses
1. Introduction
The syntax for private-key information was originally described in
[RFC5208], and the syntax was later revised by [RFC5958] to include
the AsymmetricKeyPackage content type that supports multiple
PrivateKeyInfos. This document defines PKCS #8 content types for use
with one PrivateKeyInfo and one EncryptedPrivateKeyInfo. These
content type assignments are needed for the PrivateKeyInfo and
EncryptedPrivateKeyInfo to be carried in the Cryptographic Message
Syntax (CMS) [RFC5652].
Note: A very long time ago, media types for PrivateKeyInfo and
EncryptedPrivateKeyInfo were assigned as "application/pkcs8" and
"application/pkcs8-encrypted", respectively.
2. Private-Key Information Content Types
This section defines a content type for private-key information and
encrypted private-key information.
The PrivateKeyInfo content type is identified by the following object
identifier:
id-ct-privateKeyInfo OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) ct(1) 52 }
The EncryptedPrivateKeyInfo content type is identified by the
following object identifier:
id-ct-encrPrivateKeyInfo OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) ct(1) 53 }
3. ASN.1 Module
The ASN.1 module [X680] [X690] in this section builds upon the
modules in [RFC5911].
<CODE BEGINS>
PrivateKeyInfoContentTypes
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) id-mod-pkcs8ContentType(85) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL
IMPORTS
CONTENT-TYPE
FROM CryptographicMessageSyntax-2009 -- in [RFC5911]
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) }
PrivateKeyInfo, EncryptedPrivateKeyInfo
FROM AsymmetricKeyPackageModuleV1 -- in [RFC5958]
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0)
id-mod-asymmetricKeyPkgV1(50) } ;
PrivateKeyInfoContentTypes CONTENT-TYPE ::= {
ct-privateKeyInfo | ct-encrPrivateKeyInfo,
... -- Expect additional content types -- }
ct-privateKeyInfo CONTENT-TYPE ::= { PrivateKeyInfo
IDENTIFIED BY id-ct-privateKeyInfo }
id-ct-privateKeyInfo OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) ct(1) 52 }
ct-encrPrivateKeyInfo CONTENT-TYPE ::= { EncryptedPrivateKeyInfo
IDENTIFIED BY id-ct-encrPrivateKeyInfo }
id-ct-encrPrivateKeyInfo OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) ct(1) 53 }
END
<CODE ENDS>
4. Security Considerations
The security considerations in [RFC5958] apply here.
5. IANA Considerations
For each of the private-key information content types defined in
Section 2, IANA has assigned an Object Identifier (OID). The OIDs
for the content types have been allocated in the "SMI Security for S/
MIME CMS Content Type (1.2.840.113549.1.9.16.1)" registry
[IANA-CMS-CTS] as follows:
+=========+==========================+===========+
| Decimal | Description | Reference |
+=========+==========================+===========+
| 52 | id-ct-privateKeyInfo | RFC 9939 |
+---------+--------------------------+-----------+
| 53 | id-ct-encrPrivateKeyInfo | RFC 9939 |
+---------+--------------------------+-----------+
Table 1
For the ASN.1 module in Section 3, IANA has assigned an OID for the
module identifier. The OID for the module has been allocated in the
"SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)"
registry [IANA-SMIME-MODS] as follows:
+=========+=========================+===========+
| Decimal | Description | Reference |
+=========+=========================+===========+
| 85 | id-mod-pkcs8ContentType | RFC 9939 |
+---------+-------------------------+-----------+
Table 2
IANA has updated the application/cms registration entry in the "Media
Types" registry by adding RFC 9939 to the "Interoperability
considerations" section and to the list of RFCs where Inner Content
Types (ICTs) are defined (see the "Optional parameters" section) and
by adding the following values to the list of ICTs:
* privateKeyInfo
* encrPrivateKeyInfo
IANA has also updated the "Security considerations" section in the
application/cms entry as follows:
+==========+============================================+
| RFC | CMS Protecting Content Type and Algorithms |
+==========+============================================+
| RFC 9939 | privateKeyInfo and encrPrivateKeyInfo |
+----------+--------------------------------------------+
Table 3
6. References
6.1. Normative References
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>.
[RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for
Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,
DOI 10.17487/RFC5911, June 2010,
<https://www.rfc-editor.org/info/rfc5911>.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958,
DOI 10.17487/RFC5958, August 2010,
<https://www.rfc-editor.org/info/rfc5958>.
[X680] ITU-T, "Information technology - Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ITU-T
Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,
<https://www.itu.int/rec/T-REC-X.680>.
[X690] ITU-T, "Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2021,
February 2021, <https://www.itu.int/rec/T-REC-X.690>.
6.2. Informative References
[IANA-CMS-CTS]
IANA, "SMI Security for S/MIME CMS Content Type
(1.2.840.113549.1.9.16.1)",
<https://www.iana.org/assignments/smi-numbers>.
[IANA-SMIME-MODS]
IANA, "SMI Security for S/MIME Module Identifier
(1.2.840.113549.1.9.16.0)",
<https://www.iana.org/assignments/smi-numbers>.
[RFC5208] Kaliski, B., "Public-Key Cryptography Standards (PKCS) #8:
Private-Key Information Syntax Specification Version 1.2",
RFC 5208, DOI 10.17487/RFC5208, May 2008,
<https://www.rfc-editor.org/info/rfc5208>.
Acknowledgments
Thanks to John Gray, Deb Cooley, Mohamed Boucadair, Orie Steele, and
Éric Vyncke for reviewing the document and providing comments.
Authors' Addresses
Joe Mandel
AKAYLA, Inc.
Email: joe@akayla.com
Russ Housley
Vigil Security, LLC
Email: housley@vigilsec.com
Sean Turner
sn3rd
Email: sean@sn3rd.com
AI ELI5
On this page
§1Why Key Content Types Are Needed
The syntax for private-key information was first described in RFC 5208 and later revised by RFC 5958. That revision added the AsymmetricKeyPackage content type, which supports several PrivateKeyInfo values at once.
This document covers the simpler case: one PrivateKeyInfo or one EncryptedPrivateKeyInfo. To be carried in the Cryptographic Message Syntax (CMS, RFC 5652), each needs a content type assignment, and this RFC supplies them.
The RFC also notes that, a very long time ago, media types for the same two structures were assigned as application/pkcs8 and application/pkcs8-encrypted.
A mail sorter needs a label on every parcel. Key parcels had no label yet, so this RFC makes two.
§2The Two Content Types
Section 2 defines one content type for private-key information and one for encrypted private-key information. Each is named by an object identifier (OID), a dotted number path that is assigned once and means the same thing everywhere.
id-ct-privateKeyInfoidentifies thePrivateKeyInfocontent type. It sits under the S/MIME content type arc with final number52.id-ct-encrPrivateKeyInfoidentifies theEncryptedPrivateKeyInfocontent type, with final number53.
Both live under the same parent path: iso, member-body, us, rsadsi, pkcs, pkcs-9, smime(16), ct(1).
Each label is a long number, like a library call number. One number means a plain key and the next means a locked key.
§3The ASN.1 Module
Section 3 gives the formal definition in ASN.1. The module builds on the modules in RFC 5911 and imports CONTENT-TYPE from the CMS module and PrivateKeyInfo and EncryptedPrivateKeyInfo from the module in RFC 5958.
It declares a set called PrivateKeyInfoContentTypes that holds ct-privateKeyInfo and ct-encrPrivateKeyInfo, followed by an extension marker (...) noting that more content types are expected. Each content type pairs a structure with its OID using IDENTIFIED BY.
This part is the exact wording of the labels, written in a strict language so computers all read it the same way.
§4Security Considerations
The entire section is one sentence: the security considerations in RFC 5958 apply here. This RFC defines identifiers and adds no new mechanism, so it adds no new security text.
The label does not change how safe the key is. The safety rules for the box are written in an older document.
§5IANA Registrations
IANA has assigned OID 52 to id-ct-privateKeyInfo and 53 to id-ct-encrPrivateKeyInfo in the registry for S/MIME CMS content types (1.2.840.113549.1.9.16.1). It also assigned 85 to id-mod-pkcs8ContentType, the identifier of the ASN.1 module, in the S/MIME module identifier registry (1.2.840.113549.1.9.16.0).
IANA also updated the application/cms media type entry. RFC 9939 is added to its interoperability considerations and to the list of RFCs that define inner content types, and privateKeyInfo and encrPrivateKeyInfo are added to the list of inner content types.
IANA is the keeper of the official list. It wrote the new labels into the list so nobody else uses the same numbers.
- 52id-ct-privateKeyInfo — Content type for one PrivateKeyInfo.
- 53id-ct-encrPrivateKeyInfo — Content type for one EncryptedPrivateKeyInfo.
- 85id-mod-pkcs8ContentType — Identifier of the ASN.1 module itself.