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: fot...@ssl.com w: https://www.ssl.com
