Update mechanism for the upcoming trust store

[Sean Mullan]

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.

--Sean

[1] 
https://firefox.settings.services.mozilla.com/v1/buckets/blocklists/collections/certificates/records