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
