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

From: Sean Leonard <[email-masked]>
Date: Fri, 16 Oct 2015 08:35:17 -0700

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

---

From: Sean Turner <[email-masked]>
Date: Sat, 17 Oct 2015 15:34:52 -0400

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

---

From: Sean Leonard <[email-masked]>
Date: Sun, 25 Oct 2015 03:17:25 -0700

Hello:

Just a bump to see if there are any media-types@-specific comments on 
application/pkcs8-encrypted...

Thank you,

Sean

On 10/16/2015 8:35 AM, Sean Leonard wrote:
> 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
>
> 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.
>
> Published specification:
> Machines, applications, browsers, Internet kiosks, and so on, that 
> support this standard allow a user to import, export, and exercise a 
> single private key.
>

---

From: Sean Leonard <[email-masked]>
Date: Sun, 25 Oct 2015 03:32:07 -0700

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:
> _______________________________________________
> media-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/media-types

---

From: Henrik Andersson <[email-masked]>
Date: Sun, 25 Oct 2015 11:46:41 +0100

Magic numbers are used by dumb tools. It's a courtesy to provide them,
not a requirement.

Sean Leonard skrev:
> 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
>