The keystore.pkcs12.keyProtectionAlgorithm property was introduced in
JDK 8. I don't think there are many apps using it.
Thus, I would make a decision on what you think the best solution is
long-term and then make sure you document any compatibility issues in
the CSR and release note.
My main advice is not to carry over the existing PKCS12 or pkcs12
flexibility into the new properties.
--Sean
On 9/27/18 11:27 AM, Weijun Wang wrote:
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.mul...@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.
