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

[Michael Osipov]

OK, now I see, it will probably require a "pem" style, because PKCS12
stores X.509 certs too, "x509" would be too generic.

I must admit, I have never used the KeyStore interface directly, but I
can't image that it would be too hard to add virtual aliases for.

I'd be happy to review your ideas.

Michael

Am 2019-06-02 um 17:00 schrieb Weijun Wang:
> 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.
>
> 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
>
>