Re: [media-types] Internet media type application/pkcs8-encrypted; request review

[Sean Leonard <[e-mail]>]

Hello media-types reviewers:

spt and seantek had a conversation off-list.

While we did not reach agreement on it, the TL;DR version is:

The registration for the X.690 (DER, BER) encoding of the 
EncryptedPrivateKeyInfo PDU could be:

application/pkcs8-encrypted
  with suggested file extension .p8e

OR

application/pkcs8; encrypted=true (or 1 or some such)
  with suggested file extension...probably still .p8. maybe .p8e too, 
maybe not


I guess it's worth asking the media-types folks here: what are the 
factors that weigh in for adding parameters to an existing media type, 
versus registering a new media type?

Ancillary issue: are we in agreement about what magic numbers are vs. 
are not? RFC 6838 Section 4.12 says that they "are byte sequences that 
are always present at a given place in the file and thus can be used to 
identify entities..." So they must be at a fixed place in the file, not 
"3 bytes away from that other byte that is n bytes away from the first 
byte that says how much n is", and the magic bytes must be sufficiently 
specific (not just '30h', for example, which is the start of most 
ASN.1/X.690-based serializations)?

Sean

On 10/17/2015 12:34 PM, Sean Turner wrote:
> Sean,
>
> I guess I’m confused by this request because I thought we’d agreed was an editorial errata for RFC5958 to address this issue:
>
> OLD:
>
>    .p8 files are sometimes PEM-encoded.  When .p8 files are PEM encoded
>    they use the .pem file extension.  PEM encoding is either the Base64
>    encoding, from Section 4 of [RFC4648], of the DER-encoded
>    EncryptedPrivateKeyInfo sandwiched between:
>
>     -----BEGIN ENCRYPTED PRIVATE KEY-----
>     -----END ENCRYPTED PRIVATE KEY-----
>
> NEW:
>
>    The data in .p8 files is sometimes PEM-encoded. When the data in
>    .p8 files is PEM encoded, the files use the .pem file extension.   PEM
>    encoding is either the Base64 encoding, from Section 4 of [RFC4648],
>    of the DER-encoded EncryptedPrivateKeyInfo sandwiched between:
>
>     -----BEGIN ENCRYPTED PRIVATE KEY-----
>     -----END ENCRYPTED PRIVATE KEY-----
>
> spt
>
> On Oct 16, 2015, at 11:35, Sean Leonard <[e-mail]> wrote:
>
>> To Media Types reviewers (and to relevant security folks):
>>
>> This is a first draft of a registration request for the Internet media type application/pkcs8-encrypted, for PKCS #8 EncryptedPrivateKeyInfo content.
>>
>> Feedback is appreciated.
>>
>> This registration is consistent with the recent application/pkcs8, application/pkcs10, and application/pkcs12 registrations. The relevant standard, RFC 5958, is primarily a republication of PKCS #8, and does not have its own media type registration in the text.
>>
>> Regards,
>>
>> Sean
>>
>> *****
>>
>> Type name: application
>>
>> Subtype name: pkcs8-encrypted
>>
>> Required parameters: N/A
>>
>> Optional parameters: N/A
>>
>> 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
>>
>>
> _______________________________________________
> media-types mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/media-types