Hello Sean, On 29/01/2018 04:30 μμ, Fotis Loukos wrote: > On 26/01/2018 11:31 μμ, Sean Mullan wrote: >> On 1/24/18 5:39 AM, Fotis Loukos wrote: >>>> 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. >> >> One thing we could potentially do initially is to provide a stable https >> URL where an updated blacklist could be downloaded, something like what >> Mozilla does for OneCRL [1]. This would be an initial step, not the >> whole solution of course, but it at least would allow someone to quickly >> update their JDK should a certificate need to be distrusted ASAP. >> >> Let me look into that a bit. >> >> I think implementing a dynamic solution is more challenging and would >> require more design/review, etc but feel free to provide more details on >> any additional thoughts or design sketches you might have. > > I find it pretty important to ensure that the file is also signed and > not just served over https. I was wondering if the community runs a > private CA, or has access to an HSM that can be used to generate and > store a private key that will sign these files. >
Do you have any info on this? Is there a way to sign these files securely, or should we find a different method of packaging them? Regards, Fotis > Regards, > Fotis > >> >> --Sean >> >> [1] >> https://firefox.settings.services.mozilla.com/v1/buckets/blocklists/collections/certificates/records >> >> >> > > -- Fotis Loukos, PhD Director of Security Architecture SSL Corp e: fot...@ssl.com w: https://www.ssl.com
