Internet media type application/pkcs8-encrypted rev 2
Sean Leonard <dev+ietf <at> seantek.com>
2015-11-05 05:57:28 GMT
To keep this moving, trying a different thing. Please review.
Type name: application
Subtype name: pkcs8-encrypted
Required parameters: N/A
charset: When the private key encryption algorithm incorporates a “password" that is an octet string, a
mapping between user input and the octet string is desirable. PKCS #5 [RFC2898] Section 3 recommends
"that applications follow some common text encoding rules"; it then suggests, but does not recommend,
ASCII and UTF-8. This parameter specifies the charset that a recipient SHOULD attempt first when mapping
user input to the octet string. It has the same semantics as the charset parameter from text/plain, except
that it only applies to the user’s input of the password. There is no default value.
ualg: When the charset is a Unicode-based encoding, this parameter is a space-delimited list of Unicode
algorithms that a recipient SHOULD first attempt to apply to the Unicode user input in succession, in
order to derive the octet string. The list of algorithm keywords is defined by [UNICODE]. “Tailored
operations” are operations that are sensitive to language, which must be provided as an input
parameter. If a tailored operation is called for, the exclamation mark followed by the [BCP47] language
tag specifies the language. For example, "toNFD toNFKC_Casefold!tr" first applies Normalization Form
D, followed by Normalization Form KC with Case Folding in the Turkish language, according to [UNICODE]
and [UAX31]. The default value of this parameter is empty, and leaves the matter of whether to normalize,
case fold, or apply other transformations unspecified.
Encoding considerations: binary
Carries a cryptographic private key. See Section 6 of RFC 5958.
EncryptedPrivateKeyInfo PKCS #8 data contains exactly one private key. Poor password choices, weak
algorithms, or improper parameter selections (e.g., insufficient salting rounds) will make the
confidential payloads much easier to compromise.
PKCS #8 is a widely recognized format for private key information on all modern cryptographic stacks. The
encrypted variation in this registration, EncryptedPrivateKeyInfo (Section 3, Encrypted Private Key
Info, of RFC 5958, and Section 6 of PKCS #8), is less widely used for exchange than PKCS #12, but it is much
simpler to implement. The contents are exactly one private key (with optional attributes), so the
possibility for hidden "easter eggs" in the payload such as unexpected certificates or miscellaneous
secrets is drastically reduced.
PKCS #8 v1.2, November 1993 (republished as RFC 5208, May 2008); RFC 5958, August 2010
Applications that use this media type:
Machines, applications, browsers, Internet kiosks, and so on, that support this standard allow a user to
import, export, and exercise a single private key.
Fragment identifier considerations: N/A
Deprecated alias names for this type: N/A
Magic number(s): None.
File extension(s): .p8e
Macintosh file type code(s): N/A
Person & email address to contact for further information:
Sean Leonard <dev+ietf&seantek.com>
Intended usage: COMMON
Restrictions on usage: None.
RSA, EMC, IETF
Change controller: The IETF
Provisional registration? (standards tree only): No
media-types mailing list
media-types <at> ietf.org