RFR 8076190: Customizing the generation of a PKCS12 keystore

[Weijun Wang]

Thinking about this more and there is a small problem.

Suppose a user is already using PKCS12. Since it was a security property, there are 2 ways to use it:

1. Set it in java.security. Now the user is using JDK 12 and in java.security there is an existing keystore.pkcs12.keyProtectionAlgorithm. If the user noticed it, he would realize this is the formal name and modify it. If he hasn't noticed it he would add a new line using PKCS12. But then since both exist, the "pkcs12" one will be read first.

2. Set it with Security::setProperty. This is similar to the "hasn't noticed it" case above, and his value will be ignored.

So, the user-provided PKCS12 one will only be used if the user is using an old java.security file. Do we really want to support that?


Since PKCS12 is already written into KeyStore.java, it seems the correct way is to use "PKCS12" as the formal name and use "pkcs12" as an alias. But in JDK 11, the search order is first "pkcs12" and then "PKCS12".

Or, shall we comment out the lines in java.security? They are indeed useless because default values are already hardcoded in source files.

--Max

> On Sep 27, 2018, at 10:29 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> It seems odd to support both. Once we put that into the code it’s very hard to take out in case someone is depending on it. So for the new properties I would just support one variant.