RFR CSR for 8162628: Migrating cacerts keystore to password-less PKCS12 format

[Sean Mullan]

On 6/2/19 11:00 AM, Weijun Wang wrote:
> But it still has to be a keystore. KeyStore is designed into SSL's TrustManagerFactory. JSSE has system properties javax.net.ssl.trustStore* pointing to it specifying file name, keystore type, and password. If we really use a PEM bundle, we might need to define a new keystore type "x509" or "pem". It's certainly cert-only, it might or might not be read-only. For the same reason I described in the CSR, it probably should be loadable by KeyStore.getInstance("JKS").
> 
> I can do some experiment. This won't go into JDK 13 anyway so there is time to discuss.

It sounds like it is worth exploring the benefits of a "PEM" Keystore 
implementation some more, but there is not enough time to do that in JDK 13.

Given that, I think we should delay this issue and not push it to JDK 
13. I think we want to avoid a case where we end up moving cacerts from 
JKS to PKCS12 and then changing our minds and moving it to PEM.

Let's take the additional release to work out what is the best long-term 
solution here.

--Sean

> 
> Thanks,
> Max
> 
>> On Jun 2, 2019, at 7:09 PM, Michael Osipov <1983-01-06 at gmx.net> wrote:
>>
>> Am 2019-06-02 um 12:36 schrieb Alan Bateman:
>>> On 02/06/2019 09:48, Weijun Wang wrote:
>>>> :
>>>>
>>>> There is also a compatibility impact as someone out there might be
>>>> opening cacerts directly.
>>>>
>>> A general point here is that the contents of the lib directory is not a
>>> supported interface, a point that may be relevant to the wording in the
>>> CSR.
>>
>> Correct, from a user's POV it is completely opaque to me. It is at the
>> descretion of Oracle just like the mod files, but from a packager's POV
>> I need to be able to exchange this sytemwide without much hassle wich
>> neither JDK nor PKCS12 do this atm compared to a PEM bundle.
>>
>> Michael
>