On Wed, Jan 17, 2018 at 8:18 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: > On 1/17/18 12:39, Tom Lane wrote: >> I don't know too much about the internals here, so looking at your >> list, I wonder whether "ssl_dh_params_file" ought to be treated as >> implementation-specific too. The other four files seem essential >> to any feature-complete implementation, but is that one?
> The proposed GnuTLS patch does make use of ssl_dh_params_file.
Right, but what happens if say macTLS doesn't?
There are basically two approaches we can take here:
1. All the relevant parameters are named "ssl_something", and we have to flag in the documentation any that are supported only by some implementations.
2. Parameters that might be supported only by some implementations are named with implementation-specific names, and we have to accept that there might sometimes be both "foossl_xyz" and "barssl_xyz".
What I don't want to end up with is an unholy mixture of both approaches. Therefore, if we are going to use method #2, we must be certain that the basic "ssl_" parameters are supported by every implementation, to the point where we'd reject an implementation that didn't have one. I can see that we'd reject an implementation lacking CRL support for instance, but I'm less clear that lack of configurable DH parameters should be a disqualifying feature omission. I'm prepared to be educated either way, but that's the core question here.
So in this particular case, does it mean that to do #2, we sould actually have an openssl_dh_params_file and a gnutls_dh_params_file, but only one at any given time?
Thinking on that there is also the case of file formats. What if one provider takes a cert file, but not in the same format -- should that still be ssl_cert_file, or should it be a different parameter name? Given that you can't use it to point to the same file.