77355 - support p12 mime type application/x-pkcs12

Status: RESOLVED WONTFIX

(Core :: Security: PSM, enhancement, P3)

Description

[thomask]

it will be very helpful to support a new mime type for p12 file. We
are currently supporting mime types of certificate and certificate
chain.

Support p12 mime type will allow us to remotely access the p12 files,
which provide mobility.

Comment 1

[Keyser Sose]

Marking NEW.

Comment 2

[thomask]

After talking to more people, it maybe more useful to
treat the downloaded PKCS12 blob as a virtual PKCS11
token so that you can remove the key after using it.

Considering a terminal in library for example, we do really 
want to have a way to remove the p12 after using it. So we
need a way to "logout". The "login" and "logout" metaphor
fix really well in the current PKCS11 module framework.

Comment 3

[John Unruh]

Mass assigning QA to ckritzer.

Comment 4

[John Unruh]

OS > all

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Mass reassign ddrinan's PSM bugs (with his permission) to nobody

Comment 6

[David E. Weekly]

application/x-pkcs12 is the correct MIME type for .p12 files.

On Windows, Firefox does not seem to be claiming handling for this filetype, which it ought to do and handle properly (by bringing up the client certificate import dialog).

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

This bug was miscategorized.  It's not primarily a UI bug.  

Comment 8

[Kai Engert (:KaiE:)]

I wonder, which context did this request refer to?

Maybe downloading from email attachments?

Comment 9

[김기창]

In addition to downloading as an email attachment, the request is also relevant to a situation where a client certificate is issued/presented to a user as a download link (or GET link).

See the demo site for issuing client certificates at http://foaf.me/simpleCreateClientCertificate.php 

Some banks in Korea are interested in issuing client certificates to their customers in this manner (as this solution obviates the need to deploy any plugin to handle key pair generation or CSR generation).

Comment 10

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

김기창, I am interested in hearing more about that. In particular, why don't those banks want to use the normal TLS (SSL) client certificate mechanism and <keygen> tag? Is there something we could do to improve client certificates and/or keygen to make it usable for their purposes? Please respond here or email me privately: [e-mail].

Comment 11

[김기창]

Hi Brian,
There is a long background to this :)
More than 10 years ago, Korean government decided to introduce "State licensed CA" list. These State licensed CAs opted for a unique method of storing user certificate and private key. These are stored as separate files (somewhat like server certificate and server key) in a folder named "NPKI" at a designated location in a user's hard drive or a removable drive (USB storage).
Because of this 'strange' manner of storing user certificate, all Korean users would need a browser plugin in order to use their personal certificate. Website operators (service providers) would also need a server side plugin to communicate with the client plugin. This created a "market" for local security solution providers. Korean Financial Supervisory Service (banking regulator) requires that all financial transactions must be secured with "personal certificates issued by State licensed CAs".
As a result of these regulatory quirks, serious problems arose mainly because of the deployment of client plugins. User behaviour became extremely dangerous (Korean users are 'trained' to click "INSTALL" whenever they see plugin installation security warning :) Service providers have also drastically limited the range of supported user platform to MS IE only - just to keep the maintenance cost to a manageable level. They cannot hope to serve a wide variety of user platforms (compile, deploy and maintain all those plugins are simply not feasible).
Ken Ganai blogged about this problem (the Monoculture of Korean internet environment where MS IE market share has remained upward of 99%).
Now, with the introduction of iPhone and Android phones, there is a growing pressure on the FSS (banking regulator) to drop the mandatory requirement to use "State licensed CAs' client certificates" for fiancial transactions. FSS is still resisting (this, in my view, has little to do with genuine security concern; it is rather the local security industry's lobbying effort; they want to retain the plugin market for as long as possible).
Now, some banks in Korea are finally looking into a way of abandoning plugin and State licensed CAs' personal certificate. They are studying the feasibility of issuing user certificates to their own customers (once their identity is verified by State licensed CAs personal certificate). This is why I wished to see that certificate import functionality of Firefox (in Windows OS) should be more user friendly. When a user (browsing with Firefox in Windows) receives *.p12 file and clicks it, MS Certificate Manager is launched. User goes through the certificate import steps (assuming that it will then be available for use with Firefox). But, alas, the imported certificate is 'invisible' under Firefox because it is stored in the MSCrypto Keystore.
Anyway, this problem is now more or less obsolete because HTML5 <keygen> provides a superb means of issuing user certificates. Importing the issued certificate is also painless.
I put up a demo site to show how this can be done:  https://openweb.or.kr/html5
A couple of banks are actively pursuing this path to get out of the mess they have been in for the past 10 years. 
I am also doing my best to publicise the advantages of <keygen> tag.

Comment 12

[Dana Keeler (she/her) (use needinfo) [:keeler]]

PKCS12 files can be imported using the certificate manager. We won't be adding support for automatically importing (or offering to import) these files when navigated to.