Looks good. After you update the CSR with these changes, I can review it.
--Sean
On 9/28/18 9:36 AM, Weijun Wang wrote:
Webrev updated at
http://cr.openjdk.java.net/~weijun/8076190/webrev.04/
Major changes:
1. Comment out key=value lines in java.security
2. Fix a bug in PBES2Parameters.java
3. Test no longer depends on openssl. Instead, use openssl to generate some
pkcs12 files and included in the test.
4. A new test KeyProtAlgCompat.java to ensure compatibility on pkcs12/PKCS12
names
I haven't made any change to KeyStore.java yet. CSR is also not updated.
Thanks
Max
On Sep 28, 2018, at 7:26 AM, Weijun Wang <weijun.w...@oracle.com> wrote:
I think commenting out the key=value lines in java.security will ensure
compatibility.
Also, I think it's a tiny bug between
1. KeyStore.java uses "keystore.PKCS12.keyProtectionAlgorithm"
2. PKCS12KeyStore searches for "keystore.pkcs12.keyProtectionAlgorithm" first and
"keystore.PKCS12.keyProtectionAlgorithm" next.
I would like to update KeyStore.java to use
"keystore.pkcs12.keyProtectionAlgorithm". We will keep supporting the PKCS12
name for this old property but everything else is clean.
How do you think?
Thanks
Max
On Sep 28, 2018, at 12:22 AM, Sean Mullan <sean.mul...@oracle.com> wrote:
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.
