On 1 Nov 2012, at 23:55, Weijun Wang wrote: > > > 在 Nov 1, 2012，10:49 PM，Bruce Rich <br...@us.ibm.com> 写道： > >> 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. > > Yes this is what I'm thinking about. If we are about to retire JKS, why not > cover JCEKS as well?
We have no plans to retire JKS (or JCEKS). We're just examining how best to transition the _default_ keystore format from JKS to PKCS12, in JDK 8. I don't see a need for the multi-format keystore to accommodate JCEKS since JCEKS is normally instantiated by explicitly specifying its keystore type (and not by calling KeyStore.getDefaultType()). > >> 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. > > I see. > > Thanks > Max > >> >> Bruce A Rich >> brich at-sign us dot ibm dot com >> >> >> >> >> From: Weijun Wang <weijun.w...@oracle.com> >> To: security-dev@openjdk.java.net >> Date: 10/31/2012 09:27 PM >> Subject: Re: Transitioning the default keystore format to PKCS#12 >> Sent by: security-dev-boun...@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. >> > >> >>
