Re Re: [14] RFR 8162628: Migrate cacerts keystore from JKS

Weijun Wang weijun.wang at oracle.com
Fri Feb 21 07:22:49 UTC 2020



> On Feb 21, 2020, at 2:44 AM, Michael Osipov <1983-01-06 at gmx.net> wrote:
> 
> Has there been any progress on this?

No.

There might be some performance impact. Also, we thought about embedding the certs inside JDK code. Users can still add their own trusted CA cert to the cacerts file, but this means one cannot just read this file and list all of them.

Thanks,
Max

> 
> I can see that JDK-8162628 is targeted for 15, but not fixed yet.
> This would be a tremendous improvement in JDK 15 and in 8/11 if
> backported. I don't expect PEM to be the default in 8/11, but
> configurable for PEM.
> 
> Michael
> 
> 
> Am 2019-08-16 um 03:36 schrieb Weijun Wang:
>> 
>> 
>>> On Aug 16, 2019, at 2:49 AM, Michael Osipov <1983-01-06 at gmx.net> wrote:
>>> 
>>>>>>   https://cr.openjdk.java.net/~weijun/8162628/webrev.00
>>>>>> 
>> 
>>>>> KeyStoreDelegator:
>>>>> * Please avoid iterating a list like an array and using List#get(int).
>>>> 
>>>> But I have 2 lists. It is a Pair but Java does not have it, and I don't like Map::Entry very much.
>>> 
>>> Granted, by why not use two iterators then?
>> 
>> How?
>> 
>>> 
>>>>> 
>>>>> I will also pass a pretty large cacerts with public CA and our CAs and
>>>>> see wether your parser doesn't choke on it.
>>> 
>>> Did you get a change to parse the file I have sent you?
>> 
>> Yes I tried. keytool -list accepts it and is using SHA-256 fingerprint as aliases.
>> 
>>> 
>>>> PEM is certainly slower than JKS because of text reading and de-Base64. I'll see if I can make any enhancement.
>>> 
>>> Commons Codec has a Base64InputStream. Maybe the entire file should be read as a stream with specific substreams
>>> for the base64 parts? That is, of course, much more coding work.
>> 
>> If the certs are to be parsed at loading, I'll see if I can inline a BASE64 decoder inside so it recognizes everything from BASE64 chars, -----'s, and @alias. If the cert parsing can be delayed I'll see if there is a quicker way to find the end of the cert (maybe read the first few bytes and get the length).
>> 
>>> 
>>> Looking forward for your improvements.
>>> 
>>> Do you see a change to backport this code to 11 and 8, but not changing the default keystore type? With that
>>> this great change could be available way earlier than Java 17 for most LTS people.
>> 
>> There is no need to change the default keystore type if keystore.type.compat=true and we allows a PEM keystore to be loadable as a JKS keystore.
>> 
>> I cannot say if this can be backported. It depends on the policy. On the other hand, you also know there are other vendors of JDK that could have different policies.
>> 
>> Thanks,
>> Max
>> 
>>> 
>>> Regards,
>>> 
>>> Michael
>> 
>> 
> 




More information about the security-dev mailing list