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.


Reply via email to