<div dir="ltr"><div>On Fri, 22 Sep 2017 00:29:38 +0200 Kurt Roeckx <<a href="mailto:kurt@roeckx.be">kurt@roeckx.be</a>> wrote:<br></div>> On Thu, Sep 21, 2017 at 12:03:19PM -0700, Josh Triplett wrote:<br>> > <br>> > Please ship an appropriate /usr/lib/ssl/ct_log_list.cnf .<br>> <br>> I think the problem is that there is no such thing as a<br>> appropriate file. We could do things like what Chrome supports,<br>> or what other browsers in the future support.<br>> <br>> The file probably doesn't support enough options to what we really<br>> would like to see as a policy, and I think OpenSSL lacks support<br>> for enforcing such a policy.<br>> <br>> I'm not sure that adding such a file currently has any benefit.<br>> <br>> <br>> Kurt<br><br><div>Is it appropriate for Debian to set a CT policy, beyond providing a list of CT logs? OpenSSL does support arbitrary CT policies via SSL_CTX_set_ct_validation_callback (<a href="https://www.openssl.org/docs/man1.1.0/ssl/SSL_enable_ct.html">https://www.openssl.org/docs/man1.1.0/ssl/SSL_enable_ct.html</a>), but that obviously leaves it up to individual applications to decide what their policy is. You're correct that ct_log_list.cnf doesn't allow for expressing a default policy that applies to all applications. </div><div><br></div><div>The benefit of shipping a CT log list is similar to that of shipping a set of root certificates. It saves users and applications having to curate and update this list themselves in order to benefit from Certificate Transparency. I can appreciate the argument that this is not an unreasonable burden to place on what is presumably a small set of users and applications though.</div><div><br></div><div>Following what Chrome does seems like a reasonable step, at least for now, assuming it's not a burden on the Debian OpenSSL team. Is it more time-consuming than it appears - regularly downloading a file, running a script to convert it to OpenSSL's format and shipping it?<br></div></div>