Update mechanism for the upcoming trust store

Fotis Loukos fotisl at ssl.com
Mon Jan 29 14:30:23 UTC 2018

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.


> --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

More information about the security-dev mailing list