On Wed, 13 Aug 2008, Howard Chu wrote:

Philip Guenther wrote:

...

...

OpenSSL's API for this is a bitfield with symbolic names, so there would still need to be a maintained mapping from whatever schema OpenLDAP provided to that bit set.

Yes, but there's no forward compatibility impact from this. I.e., if we have to map numbers to bitfields, we can just have a default case: if the number is higher than any we recognize, just disable all the bits we know about and assume the TLS library is smart enough to do something useful with whatever is left.

Hmm, with a warning in the docs "if you set this option to a value beyond the range understood by your version of OpenLDAP or the underlying SSL library, it may enforce a lower minimum or fail completely".

So instead of writing TLS_PROTOCOL_MIN TLSv1.0 they would write TLS_PROTOCOL_MIN 3,1

etc? I guess that's acceptable to me, albeit a little user unfriendly.

...

I guess an alternative would be to directly expose the SSL_CTX_set_options() API: TLS_OPTIONS would take a number and pass it directly to that call. Of course, the admin would have to read the .h file and do some math to figure out what to set, and there's no guarantee that OpenSSL won't change those values across a version change...

I think at this point we need to get away from using implementation-specific values. Back when OpenSSL was the only game in town I wouldn't have worried too much about it, but now it's becoming more of an issue.

I guess I shouldn't have left out the "<joke>" brackets around that.

Philip