[8u] request for review: 8062552 Support keystore type detection for JKS and PKCS12 keystores

[Vincent Ryan]

The aim of this enhancement is to address a specific compatibility risk for JKS and
not to offer a general purpose mechanism for loading any keystore type. In general,
the keystore type should match the keystore file format.

In JDK 9 there is a new probe mechanism for keystores that is more similar to
what you are proposing. The advantage of that mechanism is that the keystore
type will exactly match the keystore file format.


> On 23 May 2015, at 09:42, Thomas Lußnig <openjdk at suche.org> wrote:
> 
> Hi,
> 
> 1) Would it not be an good idea to check the first bytes of the message
> so that the dual class already know what type the stream is
> and there is no unnecessary instanciation of exceptions and engine class?
> 2) If we add an "smart" keystore why we limit it to two types? I do not
> see any reason why it should not be possible to add other store types to:
> - JCEKS
> - PKCS11
> It could be extended via securit property
> java.security.smartKeystore.<N>.type = PKCS11
> java.security.smartKeystore.<N>.magic = <HexSequence> (Optional for
> Performance)
> java.security.smartKeystore.<N>.engineClass = CanonicalEngine Class Name
> 
> This would be only an small code change but an usefull improvement.
> 
> Gruß Thomas
> 
> 
> On 22.05.2015 22:01, Sean Mullan wrote:
>> Looks fine to me.
>> 
>> --Sean
>> 
>> On 05/22/2015 03:10 PM, Vincent Ryan wrote:
>>> Thanks Thomas and Sean for your review comments.
>>> 
>>> KeyStoreDelegator matches the JDK 9 version. I’ve moved it to the
>>> sun.security.package and modified it as suggested.
>>> I also made JavaKeyStore package-private but DualFormatJKS needs to
>>> remain public.
>>> The cert in trusted.pem is an arbitrary X.509 cert and I’ve added a
>>> comment in the TestKeystoreCompat test.
>>> 
>>> A new webrev is available at:
>>> http://cr.openjdk.java.net/~vinnie/8062552/webrev.02/