Transitioning the default keystore format to PKCS#12
Michael StJohns
mstjohns at comcast.net
Thu Nov 1 17:50:25 UTC 2012
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...
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).
>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.
Mike
>Webrev:
> http://cr.openjdk.java.net/~vinnie/jdk8-multi/webrev/
>
>Please send me any comments.
>Thanks.
More information about the security-dev
mailing list