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

[Michael Osipov]

Am 2019-06-02 um 10:48 schrieb Weijun Wang:
> Oops, I thought this is about another RFE
>
>    8193255: Root Certificates should be stored in text format and assembled at build time
>
> So, are you proposing to simply put the long PEM bundle as the final cacerts in the release? In fact, I've proposed this before [1] but there were no response.
>
> The missing of alias is still a problem. There is also a compatibility impact as someone out there might be opening cacerts directly.

Your old proposal pretty nails the issue. All of the benefits/points are
valid. I see only a little gain by moving to PKCS12. If I could, I would
downvote the move to PKCS12 for public certs. It always requires
openssl(1) to modify this store.

Why do you need this alias? You could take the CN from the cert DN and
remove all spaces, perform to lower case and there you have it. If all
fails, you sill can use the serial ID from the cert.

Here is my prolonged trail to make it work on my deployment platform:
https://reviews.freebsd.org/D16352, same applies for RHEL, where I do
the same already provided by Red Hat.

In my case at work, I have the NSS (Mozilla) provided certs, plus
Siemens certs, Baltimore Trust and Quo Vadis. It is total 200 of them.
keytool is horribly slow for this, for PEM it is merely cat(1) call.

I simply don't expect Java to behave differen, but just using PEM files.

May this could be reconsidered for the entire community. JKS was an
error from begin with, it shall not be repeated.

Michael

> [1] http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016623.html
>
>> On Jun 2, 2019, at 4:34 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>
>> The main reason I put each cert in an individual file is for the file name, which will be used as the alias in the cacerts keystore.
>>
>> If all certs are in a single file, I know I can add attribute lines like "alias: name [jdk]" before each PEM block but these extra lines are not well defined and I don't like depending of them.
>>
>> Anyone else also preferring this format?
>>
>> Thanks,
>> Max
>>
>>> On Jun 1, 2019, at 7:17 PM, Michael Osipov <1983-01-06 at gmx.net> wrote:
>>>
>>> Am 2019-05-31 um 05:32 schrieb Weijun Wang:
>>>> Please review the CSR at
>>>>
>>>>    https://bugs.openjdk.java.net/browse/JDK-8224891
>>>>
>>>> (Oh, I hate the CSR having a different bug id.)
>>>>
>>>> Basically, with this change, the cacerts file can be loaded with
>>>>
>>>>    KeyStore.getInstance("JKS" or "PKCS12").load(stream, null or anything) or
>>>>    KeyStore.getInstance(new File("cacerts"), null or anything)
>>>>
>>>> so hopefully all your old code should still work.
>>>>
>>>> I've also opened another RFE [1] that intends to find a different way to tag jdkCA entries in cacerts other than appending "[jdk]" to the alias.
>>>
>>> Can you please explain why not simple PEM bundles like OpenSSL have been
>>> chosen? This could have eased maintenance by factors, plus it is easy
>>> greppable.
>>
>
>