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. >
