When buying a code-signing certificate, what are the merits of starting with a PKCS12 versus JKS certificate? Some vendors give instructions on starting with a JKS or PKCS12 certificate signing request. We'd like to have maximum flexibility in using a purchased cert, especially given the cost. For example, we may be signing more than just Java code (ex: iPhone or Android code signing). What technical considerations should we take into account when choosing either approach?
A:
If you're working in Java then the Java Key Store is a fairly natural place to store private keys.Java applications typically expect to get the keys they need from JKS, and it's easy to access from your own Java apps. JKS is not accessible (without jumping through a few hoops) from outside Java, though.
PKCS#12 (aka PFX) files, on the other hand are a language-neutral way to store encrypted private keys and certificates, and has been around long enough that it's supported just about everywhere. Note, though, that the file format is horribly over-complex and over-general -- have a look at Peter Gutmann's "PFX - How Not to Design a Crypto Protocol/Standard" (http://www.cs.auckland.ac.nz/~pgut001/pubs/pfx.html) for a light-hearted view of the problems.
Note that the use of one or other of these storage formats is really an issue about how your application will store encrypted private keys locally. The vendor who sells you your certificate will never see the private key so he doesn't care what format you use. You send him (the vendor/CA) a PKCS#10 certificate request (containing the public key and signed using the private key, but NOT containing the private key) and he sends you back a certificate (which you can store in JKS or in the PKCS#12 file or both, or anywhere else that takes your fancy).
Technically, neither format is ideal as they both protect the private key by encrypting it with a key derived from a password; this doesn't make either one better than the other, thoutgh. Security (though not convenience) is better if you can use a smartcard or other hardware key storage solution.
The main factor determining your choice should be how you plan to use the private key -- that is: what applications will need to use the private key and what format(s) of key store do they already handle. PKCS#12 is the more flexible option ... but if you intend to use the key only with code that you write yourself (interoperability not required) then you might also consider using PKCS#8 or PKCS#15 containers.
I can't recommend writing your own code to handle PKCS#12 (I've done it, not fun) -- use a proven third-party library (like OpenSSL).
dajames
2010-10-14 11:28:18