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

From: Sean Leonard <[email-masked]>
Date: Mon, 29 Dec 2014 02:36:45 -0800

To Media Types reviewers (et. al.):

This is a first draft of a registration request for the Internet media 
type application/pkcs12, for PKCS #12 content.

Per RFC 6838, I do not believe that this registration requires a formal 
RFC since it is from a recognized standards organization (IETF itself). 
Feedback is appreciated.

This registration is consistent with the recent application/pkcs8 and 
application/pkcs10 registrations. The relevant standard, RFC 7292, is 
primarily a republication of PKCS #12, and does not have its own media 
type registration in the text.

Regards,

Sean

*******

Registration Template [DRAFT]

Type name: application

Subtype name: pkcs12

Required parameters: N/A

Optional parameters: N/A

Encoding considerations: binary

Security considerations:
PKCS #12 data typically contains one or more private keys encrypted with 
a password using a key derivation function. Poor password choices, weak 
algorithms, or improper parameter selections (e.g., insufficient salting 
rounds) will make the confidential payloads much easier to compromise. 
Additionally, PFX was subject to criticism for being too obtuse and 
cumbersome to implement (see Gutmann, P., PFX - How Not to Design a 
Crypto Protocol/Standard, 
<https://www.cs.auckland.ac.nz/~pgut001/pubs/pfx.html>). Many of these 
(editorial) shortcomings have been addressed in the latest publications 
of PKCS #12.

Interoperability considerations:
PKCS #12 (formerly PFX, Personal Information Exchange) is a widely 
recognized format for exchange of secret (personal identity) information 
on all modern cryptographic stacks. The format is primarily used for the 
exchange of private keys and certificates, but can also be used to 
exchange symmetric keys, miscellaneous secrets, attributed objects, and 
extensions.

Published specification:
PKCS #12 v1.0, June 1999; PKCS #12 v1.1 (RFC 7292), July 2014

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 set of personal identity information.

Fragment identifier considerations: N/A

Additional information:

  Deprecated alias names for this type: N/A
  Magic number(s): 30h at octet 0
  File extension(s): .p12, .pfx
  Macintosh file type code(s): N/A

Person & email address to contact for further information:
  Sean Leonard <[email-masked]>

Intended usage: COMMON

Restrictions on usage: None.

Author:
(originally Microsoft), RSA, EMC, IETF

Change controller: The IESG (?)

Provisional registration? (standards tree only): No

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Mon, 29 Dec 2014 14:02:55 +0000

Hi Sean,

Thanks for the review.  I just have one comment inline.

Sent from my iPhone

> On Dec 29, 2014, at 5:37 AM, "Sean Leonard" <[email-masked]> wrote:
> 
> This is a first draft of a registration request for the Internet media type application/pkcs12, for PKCS #12 content.
> 
> Per RFC 6838, I do not believe that this registration requires a formal RFC since it is from a recognized standards organization (IETF itself). Feedback is appreciated.
> 
> This registration is consistent with the recent application/pkcs8 and application/pkcs10 registrations. The relevant standard, RFC 7292, is primarily a republication of PKCS #12, and does not have its own media type registration in the text.
> 
> Regards,
> 
> Sean
> 
> *******
> 
> PKCS #12 data typically contains one or more private keys encrypted with a password using a key derivation function. Poor password choices, weak algorithms, or improper parameter selections (e.g., insufficient salting rounds) will make the confidential payloads much easier to compromise. Additionally, PFX was subject to criticism for being too obtuse and cumbersome to implement (see Gutmann, P., PFX - How Not to Design a Crypto Protocol/Standard, <https://www.cs.auckland.ac.nz/~pgut001/pubs/pfx.html>). Many of these (editorial) shortcomings have been addressed in the latest publications of PKCS #12.
> 
> PKCS #12 (formerly PFX, Personal Information Exchange) is a widely recognized format for exchange of secret (personal identity) information on all modern cryptographic stacks. The format is primarily used for the exchange of private keys and certificates, but can also be used to exchange symmetric keys, miscellaneous secrets, attributed objects, and extensions.
> 
> Published specification:

Magnus was with RSA during his work on this work which was originally done at RSA.  He is now at Microsoft.  All of the work was done at RSA and this version republished v1.1 from the RSA publication handing over change control to the IETF.

Thanks,
Kathleen

---

From: Sean Leonard <[email-masked]>
Date: Mon, 29 Dec 2014 09:43:26 -0800

Thank you for the fast response. The revised section is proposed to read:

Author:
RSA, EMC, IETF

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Mon, 29 Dec 2014 18:32:24 +0000

Thank you, Sean.

Sent from my iPhone

> On Dec 29, 2014, at 12:43 PM, "Sean Leonard" <[email-masked]> wrote:
>

---

From: "John Levine" <[email-masked]>
Date: 29 Dec 2014 21:09:12 -0000

>type application/pkcs12, for PKCS #12 content.

I have no objection to the type, but I do wonder how likely it is to
be used.  PKCS #12 and PFX have been around for 20 years, and I don't
ever recall seeing a p12 sent as a message body.

R's,
John

---

From: Sean Leonard <[email-masked]>
Date: Mon, 29 Dec 2014 13:15:22 -0800

> ever recall seeing a p12 sent as a message body.

It happens. I have seen them regularly. (Typically the password/secret information is sent OOB.) Additionally, they can be uploaded and downloaded via HTTP(S).

Currently application/x-pkcs12 is in certain applications, namely Apache:
https://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/conf/mime.types

and MS Windows:
(See HKEY_CLASSES_ROOT\Mime\Database)

Sean

---

From: "John Levine" <[email-masked]>
Date: 30 Dec 2014 00:05:44 -0000

>https://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/conf/mime.types

By golly, there it is in the Apache 2.4 default config.  "Never mind."

R's,
John

---

From: Jo Wilkes <[email-masked]>
Date: Tue, 30 Dec 2014 17:25:45 +0100

Had similar doubts, thanks for putting them at rest.

I have seen application/pkcs-12 and application/x-pkcs12 in the wild. I think it's better to have an official media type where the subtype name fits the established pattern without dash (application/pcks10, application/pcks8, application/pcks7-mime). So I'm generally in favour of this request.

One nitpick, still: Specifying 30h at octet 0 as Magic number irritates me. The majority of ASN.1 formats starts with a sequence, so this byte is not a distinctive criterion. If we cannot get an unique value, could we omit this?

Regards, 
and a good new year to you
Jo

---

From: Sean Leonard <[email-masked]>
Date: Tue, 30 Dec 2014 08:52:29 -0800

(Adding pkcs 12 authors back)

> I have seen application/pkcs-12 and application/x-pkcs12 in the wild. I think it's better to have an official media type where the subtype name fits the established pattern without dash (applicatio…

Great!

> One nitpick, still: Specifying 30h at octet 0 as Magic number irritates me. The majority of ASN.1 formats starts with a sequence, so this byte is not a distinctive criterion. If we cannot get an un…
RFC 6838 says:

    Various sorts of optional information SHOULD be included in the
    specification of a media type if it is available:

    o  Magic number(s) (length, octet values).  Magic numbers are byte
       sequences that are always present at a given place in the file and
       thus can be used to identify entities as being of a given media
       type.

********

I don't think this language supports the premise that the Magic Number 
needs to uniquely identify this type of data *and* nothing else in the 
universe. (I.e., the language is inclusive, not exclusive.) Like file 
name extensions, there is no way to reserve a particular set of magic 
numbers for one format's exclusive use: anyone can invent a new format 
that reuses the magic numbers. Finding 30h at least puts you in the 
right ballpark, so you can defer to an ASN.1 processor to give you more 
details.

With regard to PKCS #12 specifically, however, one *might* find the 
following magic number OIDs throughout the data (BER-encoded):
1.2.840.113549.1.7.1 - PKCS #7 data
1.2.840.113549.1.7.6 - PKCS #7 EncryptedData
1.2.840.113549.1.12.10.1.2 - pkcs-12-pkcs-8-ShroudedKeyBag

Also, the PKCS #12 is guaranteed to have the following ASN.1 data:
SEQUENCE of INTEGER, SEQUENCE, and SEQUENCE (of SEQUENCE, OCTET STRING, 
and optional INTEGER).
...which is not guaranteed to be DER encoded (it could be 
indefinite-length BER, for example).

This is based on a non-representative sample (i.e., a p12 file I 
happened to find lying around).

Per the above guidance however this is delving a bit too much into the 
byte stream for a magic number analysis.

Cheers,

Sean

---

From: Jo Wilkes <[email-masked]>
Date: Tue, 30 Dec 2014 19:21:47 +0100

At 2014-12-30 T 17:52 Sean Leonard wrote:
> I don't think this language supports the premise that the Magic Number needs to uniquely identify this type of data *and* nothing else in the universe. (I.e., the language is inclusive, not exclusive.) Like file name extensions, there is no way to reserve a particular set of magic numbers for one format's exclusive use: anyone can invent a new format that reuses the magic numbers. Finding 30h at least puts you in the right ballpark, so you can defer to an ASN.1 processor to give you more details.
> 
> With regard to PKCS #12 specifically, however, one *might* find the following magic number OIDs throughout the data (BER-encoded):
> SEQUENCE of INTEGER, SEQUENCE, and SEQUENCE (of SEQUENCE, OCTET STRING, and optional INTEGER).
> ...which is not guaranteed to be DER encoded (it could be indefinite-length BER, for example).
> 
> This is based on a non-representative sample (i.e., a p12 file I happened to find lying around).
> 
> Per the above guidance however this is delving a bit too much into the byte stream for a magic number analysis.

I've written my share of ASN.1 encoding/decoding and PKCS code, so I'm aware this is tricky.
And if I had a perfect magic ID ready (above examples are along my lines of thought), I would have proposed it.

(A partial DER-OID encoding of "1.2.840.113549.1" 06 07 2A 86 48 86 F7 0D 01 => so "2A 86 48 86 F7 0D 01" could be used to match most PKCS#12 files. Maybe not all possible ones, and the position isn't fixed. - BTW, doesn't PCKS#12 require the x509 cert to be DER-encoded?)

But a single h30? In ASCII, that's a "0".

I'm aware that a magic number isn't an reserved unique identifier. But I think it should be specific enough so using it is a benefit.
A rule that uses it should on average deliver more correct matches than false positives.
"File starts with ASCII 0" is not good enough for my taste, so that's why I suggest to omit it. 

YMMV.

Cheers

Jo

---

From: Sean Leonard <[email-masked]>
Date: Tue, 30 Dec 2014 11:06:17 -0800

> (A partial DER-OID encoding of "1.2.840.113549.1" 06 07 2A 86 48 86 F7 0D 01 => so "2A 86 48 86 F7 0D 01" could be used to match most PKCS#12 files. Maybe not all possible ones, and the position is…

Nope. See draft-josefsson-pkix-textual-10 for extensive discussion on 
why DER encoding can't be assumed.

> "File starts with ASCII 0" is not good enough for my taste, so that's why I suggest to omit it.

Well..............

I checked some other PKIX registrations, namely application/pkix-cert, 
application/pkix-crl, application/pkix-attr-cert, application/pkcs8, and 
application/pkcs10...and none of those specify magic numbers. 
(application/pkix-pkipath does but we can just sweep that one under the 
rug.)

I am okay with changing it to "None." Therefore the template is hereby 
revised to say:

   Magic number(s): None.

-Sean