RFR 8076190: Customizing the generation of a PKCS12 keystore

[Sean Mullan]

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.wang at 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.mullan at 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.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.
>>
>