Update mechanism for the upcoming trust store

[Sean Mullan]

Hi Fotis,

This is an interesting issue and I agree it is important. From your post 
it seems that each implementation has come up with a different mechanism 
for solving this problem, which is unfortunate - it would be more ideal 
if we could converge on a standard mechanism for addressing it. There 
certainly seems that there is a need for that. Do you know if anything 
is being discussed along those lines?

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.

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.

Thanks,
Sean

On 1/18/18 11:03 AM, Fotis Loukos wrote:
> Hello everybody,
> I am watching the effort of the community to create a new trust store
> (JEP319). Based on the description, a trust store will be created which
> will be shipped with every release.
> I think that this is a really good step, however I believe that a
> different approach should be used, namely create an API that will be
> used to automatically populate the local trust store. If not a full API,
> even downloading the cacerts file from a secure location would be better.
> This will help in applying trust decisions in a more efficient way. Past
> experience has shown us that there have been CAs which unfortunatelly
> misissued certificates. One of the most famous examples is the Diginotar
> case. Waiting for the next release of openjdk may leave a lot of people
> vulnerable to such attacks at CAs. Most major trust store operators have
> already implemented mechanisms to immediately take trust decisions,
> until they are integrated in the next release. For example, Mozilla uses
> OneCRL and Google uses CRLSet. Microsoft has taken a different approach
> and publishes their whole trust store using the authroot.stl file and
> specific distrusted certs using the disallowedcerts.stl file. The same
> approach is being used by Adobe publishing the trust store at
> http://trustlist.adobe.com/tl12.acrobatsecuritysettings and Cisco
> publishing the different trust stores under
> https://www.cisco.com/security/pki/trs/. These trust stores are
> regularly fetched in order for the operators to be able to respond to CA
> security incidents as soon as possible. As far as I know, Apple is going
> to create an API for this.
> Publishing the whole trust store will also help developers who create
> validation programs that check against different trust stores. Many
> sites exist such as the ssl labs tests, that need to have access to a
> software's trust store, and making an automated mechanism to fetch it
> would be really useful.
> 
> Regards,
> Fotis Loukos
>