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: [email protected] w: https://www.ssl.com
