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

[Sean Turner <[e-mail]>]

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
> 
>