The updated InitializationData must provide functions / entry points that allows the application to configure SSL/TLS for :
the client-side (the outgoing connections created by the communicator), and
the server-side, on a per-OA basis, keyed by the OA name
These functions must in particular be sufficient to update/reload the certificates, assuming the underlying SSL/TLS library provides this feature (which is likely). See #334.
The only way to "program" IceSSL is through the native API exposed via InitializationData.
d) Drop the OpenSSL support on Windows.
We could build the Ice core on Windows for both OpenSSL and SChannel, but it's obviously more work and we don't really need this additional SSL option.
pepone
commented
3 weeks ago
Having IceSSL as a plugin introduces complexity and makes configuration difficult.
I propose to:
a) Merge IceSSL into the Ice core
This way, the IceSSL layer becomes built-in and always available.
We would nevertheless keep the existing IceSSL configuration for backwards compatibility. See https://doc.zeroc.com/ice/3.7/property-reference/icessl
b) Give full access to the underlying SSL/TLS library in InitializationData
See https://doc.zeroc.com/ice/3.7/communicator-and-other-core-local-features/communicator-initialization#id-.CommunicatorInitializationv3.7-InitializationData
The updated InitializationData must provide functions / entry points that allows the application to configure SSL/TLS for :
These functions must in particular be sufficient to update/reload the certificates, assuming the underlying SSL/TLS library provides this feature (which is likely). See #334.
c) Drop most of (or all) the public API of IceSSL
See https://doc.zeroc.com/ice/3.7/ice-plugins/icessl/programming-icessl
The only way to "program" IceSSL is through the native API exposed via InitializationData.
d) Drop the OpenSSL support on Windows.
We could build the Ice core on Windows for both OpenSSL and SChannel, but it's obviously more work and we don't really need this additional SSL option.