]> AKAYLA, Inc.

joe@akayla.com

Vigil Security, LLC

housley@vigilsec.com

sn3rd

sean@sn3rd.com

Security Limited Additional Mechanisms for PKIX and SMIME This document defines PKCS #8 content types for use with PrivateKeyInfo and EncryptedPrivateKeyInfo as specified in RFC 5958. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Limited Additional Mechanisms for PKIX and SMIME mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The syntax for private-key information was originally described in , and the syntax was later revised by to include the AsymmetricKeyPackage content type that supports multiple PrivateKeyInfos. This document defines PKCS #8 content types for use with one PrivateKeyInfo and EncryptedPrivateKeyInfo. These content type assignments are needed for PrivateKeyInfo and EncryptedPrivateKeyInfo to be carried in the Cryptographic Message Syntax (CMS) . Note: A very long time ago, media types for PrivateKeyInfo and EncryptedPrivateKeyInfo were assigned as application/pkcs8 and application/pkcs8-encrypted, respectively.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

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: The EncryptedPrivateKeyInfo content type is identified by the following object identifier:

ASN.1 Module The ASN.1 module in this section builds upon the modules in .

Security Considerations The security considerations in apply here.

IANA Considerations For the private key info content types defined in section , IANA is requested to assign an object identifier (OID) for each of the content types. The OIDs for the content types should be alloacted in the "SMI Security for S/MIME CMS Content Type" registry (1.2.840.113549.1.9.16.1), and the description should be set to id-ct-privateKeyInfo (TDB1) and id-ct-encrPrivateKeyInfo (TBD2). For the ASN.1 Module in , IANA is requested to assign an object identifier (OID) for the module identifier. The OID for the module should be allocated in the "SMI Security for S/MIME Module Identifier" registry (1.2.840.113549.1.9.16.0), and the Description for the new OID should be set to "id-mod-pkcs8ContentType".

References Normative References This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] This document defines the syntax for private-key information and a content type for it. Private-key information includes a private key for a specified public-key algorithm and a set of attributes. The Cryptographic Message Syntax (CMS), as defined in RFC 5652, can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type. This document obsoletes RFC 5208. [STANDARDS-TRACK] The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. ITU-T ITU-T In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document represents a republication of PKCS #8 v1.2 from RSA Laboratories' Public Key Cryptography Standard (PKCS) series. Change control is transferred to the IETF. The body of this document, except for the security considerations section, is taken directly from the PKCS #8 v1.2 specification. This document describes a syntax for private-key information. This memo provides information for the Internet community.

Acknowledgments Thanks to John Gray and Deb Cooley for reviewing the document and providing comments.