]> PKCS #8 Private-Key Information Content Types 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 later obsoleted by . This document defines PKCS #8 content types for use with PrivateKeyInfo and EncryptedPrivateKeyInfo.
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:
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".
ASN.1 Module
Normative References Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification Version 1.2 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. Asymmetric Key Packages 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] New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME 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. Key words for use in RFCs to Indicate Requirement Levels 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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.
Acknowledgments TODO acknowledge.