Update mechanism for the upcoming trust store

Fotis Loukos fotisl at ssl.com
Thu Jan 18 16:03:44 UTC 2018

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.

Fotis Loukos

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