Transitioning the default keystore format to PKCS#12

Bruce Rich brich at us.ibm.com
Thu Nov 1 14:49:38 UTC 2012


Max,

There is already substantial usage of JCEKS to store secret keys.  And 
that has been operational since Java 5. 
So I'm not sure what question you are asking.  One might have asked 
whether the multi-format keystore would also accommodate JCEKS. 
If that was your question, I think it would increase the scope beyond what 
can be accomplished in the near term, which is why the focus is on JKS, 
which is the format used by cacerts, for example.

Bruce A Rich
brich at-sign us dot ibm dot com




From:   Weijun Wang <weijun.wang at oracle.com>
To:     security-dev at openjdk.java.net
Date:   10/31/2012 09:27 PM
Subject:        Re: Transitioning the default keystore format to PKCS#12
Sent by:        security-dev-bounces at openjdk.java.net



A little off topic:

Do we still care about the JCEKS storetype? Maybe no one stores secret 
keys in a keystore?

Thanks
Max


On 11/01/2012 12:55 AM, 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.
>
> 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.
>
> Webrev:
>    http://cr.openjdk.java.net/~vinnie/jdk8-multi/webrev/
>
> Please send me any comments.
> Thanks.
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20121101/c9b5344c/attachment.htm>


More information about the security-dev mailing list