Re: [precis] [media-types] Internet media type application/pkcs8-encrypted rev 3

[Sean Leonard <[e-mail]>]

Hello:

This is rev 3 of the application/pkcs8-encrypted template. It continues 
the progression from the thread at the end of November.

Sean

************

Type name: application

Subtype name: pkcs8-encrypted

Required parameters: N/A

Optional parameters:

password-mapping:
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 similar 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.

The following special values are defined:
*pkcs12  = UTF-16LE with U+0000 NULL terminator (PKCS #12-style)
*precis  = PRECIS password profile, i.e., OpaqueString from Section 4 of RFC 7613 (always UTF-8)
*precis-XXX = PRECIS profile as named XXX in the IANA PRECIS Profiles Registry <https://www.iana.org/assignments/precis-parameters>
*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, the final digit 0 is appended, or an error condition may be 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. (This is to support restricted-input devices, i.e., telephones and telephone-like equipment.)

Otherwise, the value of this parameter is a charset, from the Character Sets Registry <http://www.iana.org/assignments/character-sets>.

Encoding considerations: binary

Security considerations:
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.

Interoperability considerations:
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.

Published specification:
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

Additional information:

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.

Author:
RSA, EMC, IETF

Change controller: The IETF

Provisional registration? (standards tree only): No