Update mechanism for the upcoming trust store

[Fotis Loukos]

Hello Sean,

On 23/01/2018 09:12 μμ, Sean Mullan wrote:
> 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?

There is RFC5914 which describes the Trust Anchor Format. It can be used
to create a trust store by populating a TrustAnchorList SEQUENCE. I am
not sure if there is some standard implementation in Java, but it
shouldn't be difficult to implement something like this.

In order to be able to verify the data, I think that the best practice
is to encapsulate and sign everything using the CMS/PKCS#7 format, as
described in RFC5652. The signing certificate could chain to a CA which
is built in the JDK.

Thus, you will only have to include a single certificate in the JDK
which will be used to verify the whole trust store. Of course, after
parsing it, it can be converted to some other format. I would suggest to
keep all the information in the TrustAnchorInfo structure for every CA
in order to be able to support other extensions in the future, such as
EV certificates.

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

Regards,
Fotis Loukos

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


-- 
Fotis Loukos, PhD
Director of Security Architecture
SSL Corp
e: fotisl at ssl.com
w: https://www.ssl.com