Transitioning the default keystore format to PKCS#12

[Vincent Ryan]

On 1 Nov 2012, at 17:50, Michael StJohns wrote:

> At 12:55 PM 10/31/2012, Vincent Ryan wrote:
> 
>> Before considering migrating the platform default keystore format to PKCS12 its keystore implementation
>> must at least match the functionality of JKS.
>> 
>> I have developed a prototype of a multi-format keystore that understands both JKS and PKCS12
>> formats - it checks for the JKS magic number to determine the format. By supporting both formats,
>> existing applications that access keystores using the platform default keystore format, continue to
>> function as expected.
> 
> 
> I think you may need to define a new keystore type for this provider instead of just reusing "pkcs12".   Either that or come up with a way to determine the keystore type from the keystore BEFORE creating an instance of the provider.  For example, you open up an old keystore of JKS type, you update it and you write it back. Do you write it back as a pkcs12 or jks?  Either choice you make is somewhat of a surprise...

If a keystore is loaded in JKS format then it is stored in JKS format too. And similarly for PKCS12 keystores.
New keystores in JDK8 would be created in PKCS12 format and new keystores in prior releases would be
created in JKS format.

Are you saying that it would be confusing for developers if the SunJSSE provider is capable of processing
a keystore in JKS format (previously the responsibility of the Sun provider)?


> 
> The other thing going on here is that pkcs12 is used almost entirely for one private key and one cert (with the possible addition of certs in the cert chain of trust).   While what you're doing is acceptable to the PKCS12 standard, I'm not sure it won't be confusing for other programs (simple check is to put multiple certs and keys in a file, and then try and import them using the microsoft cert tool).
> 
> 

I haven't tried using the Microsoft cert tool yet but OpenSSL seems happy enough.


> 
> 
> 
> 
>> In addition, storing trusted certs in PKCS12 is now supported. I've selected the X.509
>> extendedKeyUsage attribute to explicitly denote that a certificate is trusted - its default value is
>> trusted-for-any-purpose. This well-known attribute is stored with the certificate in a PKCS12
>> certBag.
> 
> 
> Before doing this, I'd suggest asking the IETF - probably the pkix working group - for comments.  I think they'll probably ask that you use something like id-kp-rootOfTrust (a OID to be defined), rather than the generic "AnyUsage".  Alternately, an Attribute with an oid of rootOfTrust with a null body may be a better choice.   Whichever you decide, it would be more than useful to document the usage and get the OID assignment.
> 

The appeal of re-purposing the extendedKeyUsage attribute is that it is already well known as a certificate extension. And in addition, it can be used by keystore owners to limit a cert's trust level to quite specific purposes.

Thanks.



> Mike
> 
> 
> 
>> Webrev:
>> http://cr.openjdk.java.net/~vinnie/jdk8-multi/webrev/
>> 
>> Please send me any comments.
>> Thanks.
> 
>