Update mechanism for the upcoming trust store

[Fotis Loukos]

Hello Sean,

On 29/01/2018 04:30 μμ, Fotis Loukos wrote:
> On 26/01/2018 11:31 μμ, Sean Mullan wrote:
>> On 1/24/18 5:39 AM, Fotis Loukos wrote:
>>>> You may not be aware, but the JDK does currently support a mechanism for
>>>> blacklisting certificates. The lib/security/blacklisted.certs file
>>>> contains a list of the fingerprints of certificates that are explicitly
>>>> distrusted. If a root was compromised and added to this file it would no
>>>> longer be trusted.
>>> My biggest concern is what you describe below, the dynamic update.
>>>
>>>> However, currently there is no mechanism in OpenJDK to dynamically
>>>> update that file. While I think there is merit in implementing something
>>>> like that, many challenges would need to be addressed as part of that,
>>>> for example, where and how does this file get updated, how is it
>>>> verified, etc.
>>> The verification step can be implemented as described above. I think
>>> that the update step requires some design, but I don't think it is that
>>> difficult. For example, a naive algorithm such as every Monday plus a
>>> random number of days/hours/minutes in order to avoid heavy traffic
>>> during the update period would be good for starters. As a first step to
>>> try a new format, you could even fetch it once during installation and
>>> provide a means for the user to update it manually.
>>
>> One thing we could potentially do initially is to provide a stable https
>> URL where an updated blacklist could be downloaded, something like what
>> Mozilla does for OneCRL [1]. This would be an initial step, not the
>> whole solution of course, but it at least would allow someone to quickly
>> update their JDK should a certificate need to be distrusted ASAP.
>>
>> Let me look into that a bit.
>>
>> I think implementing a dynamic solution is more challenging and would
>> require more design/review, etc but feel free to provide more details on
>> any additional thoughts or design sketches you might have.
> 
> I find it pretty important to ensure that the file is also signed and
> not just served over https. I was wondering if the community runs a
> private CA, or has access to an HSM that can be used to generate and
> store a private key that will sign these files.
> 

Do you have any info on this? Is there a way to sign these files
securely, or should we find a different method of packaging them?

Regards,
Fotis

> Regards,
> Fotis
> 
>>
>> --Sean
>>
>> [1]
>> https://firefox.settings.services.mozilla.com/v1/buckets/blocklists/collections/certificates/records
>>
>>
>>
> 
> 


-- 
Fotis Loukos, PhD
Director of Security Architecture
SSL Corp
e: fotisl at ssl.com
w: https://www.ssl.com