Gregory,
>> * - Windows indeed will not handle a .p12 cert+key with the PKCS5 v2 [i.e.
>> aes-256] encryption on it. It appears to only handle 3DES. [I didn't test
>> every possible PBE - just 3DES and AES256]
The Microsoft Windows operating system uses Cryptographic Service Provider
(CSP) plug-in modules to do the actual implementation of the cryptographic
functions so that Microsoft can ship their products world-wide, including to
countries where cryptography may be restricted. The Base CSP shipped with all
recent versions of Microsoft Windows is most likely restricted to
lower-strength cryptography.
For a more complete discussion of this concept and to find out what providers
are available for your country, see the MSDN article here:
http://msdn.microsoft.com/en-us/library/aa386983.aspx
According to the MSDN article referenced; in the US, Microsoft _does_ provide
full support for AES-256 algorithms, but it is probable that the CSP that
provides this capability might not be loaded by default on the operating system
baseline.
Apple also uses this concept of "Cryptographic Service Provider", so search
their web site(s) using this term. you may also be able to leverage Java and
OpenSSL as the Apple OS X is UNIX-based.
Java 6 SE (and above) supports this under Java Cryptographic Architecture (JCA)
and Java Secure Sockets Extensions (JSSE), splitting the API and
implementations using a similar concept of Providers.
A good starting point for Oracle Java Cryptographic Architecture that discusses
which Providers are available is at this URL:
http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html
Good luck with your testing of .p12.
Cheers!
Simba
Engineering
While this, as far as I can tell, is all true - it's also somewhat misleading.
It's true that Windows and OSX have underlying API's and functions that will
handle AES etc - but that only helps if you're planning to code/program your
own tools to import p12's. It won't help if you're an "end-user" or IT Admin
person using the built-in tools [certmgr.msc] and the iOS keychain importer,
etc. These built-in tools only understand p12's with 3DES and there's no way
around that, as far as I can tell.
And frankly it would be insane for me to spend, probably, hundreds of hours
[yeah, I am a lousy programmer. :)] learning the respective API's and such,
just so I could code a way to import AES encrypted P12's into Windows. And then
do it all over again for iOS and again for OSX.
You're not the only one to suggest this - and I really don't mean to make light
of the suggestion, it's a valid suggestion - but it just doesn't make sense in
the current context.
The bigger take-home issue is: Why Microsoft and Apple haven't updated their
PKCS import tools in so freeking long and still appear to only support 3DES
encryption of keys? This seems really irresponsible to me. It's not like 3DES
is so horrible - but it's really not that great with ~112bit key vs 256bit key
for AES-256.
I'd feel a lot more secure emailing a p12 with a private key to someone with a
good tough password and AES-256 than I would with 3DES. And in quite a number
of cases, it's far easier to distribute them this way - a web-server, FTP,
email...
Just try getting a p12 to an iOS device. iTunes, email, web-browser and that's
basically it. [But iOS and iTunes just to copy a few files!?!? - well that's
another unhinged rant for another thread... <unhinged manic laugh>...]
Thanks for the suggestion though! I do appreciate the time and effort expended,
even if it doesn't make sense for me.
-Greg
