Page History

...

1. Should not ideally we move out the common SSL configurations in the EncryptionOption and may be define a parent class like CommonEncryptionOption?
   1. Response: Ideally yes. While it is little weird to have conflicting configuration options in the EncryptionOption (i.e. file based keystore/truststore paths and pluggable sslcontext factory which mostly intended toward not using file based artifacts), practically we could still live with little imperfection. However we will be open to discuss if the community members feel it is best to have a parent class to move out 'common' ssl configurations between file based and pluggable sslcontext factory.
   2. Above stated reason results into the current design of the interface which requires EncryptionOptions to be passed to most of it's methods because the implementation needs to know the "common SSL configurations".
2. Should we move to model of having Map<String,String> type as passing all the SSL configuration options to any implementation of the ISslContextFactory including the Default/Common one?
   1. Yes we could do that but for that we would have to "copy" all the common SSL configurations to the Map<String,String> while creating the instance of the ISslContextFactory's implementation including the Default one. This would also help make the imperfection of not adding CommonEncryptionOption suggested in the 1st question.
   2. Doing this will mean we need to add 'getAcceptedProtocols()' method, equivalent of this current method, in ISslContextFactory. If we do that the pluggable implementation have to define accepted protocol list. Based on this 

      Jira
      server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key CASSANDRA-13325

       it is clear that we should honor, for security reasons, the current processing of the accepted_protocols and protocol configurations and not leave a room for the implementations to make a mistake opening a security hole. For this particular reason the above option (having CommonEncryptionOptions) makes more sense.
   3. Again, we would need community's input on the preference.

...