If I understand correctly, you are proposing to abandon the idea of a pluggable extension point for SSL in Kafka because we could rely on the JCE provider mechanism.
I will reiterate that nobody does it that way. That in itself should be enough but let's discuss some of the reasons why. Changing the order of the JCE providers in the java.security file affects all java applications so you probably don't want to do it there. Changing the order of the JCE providers in the JVM instance affects all code it runs. Your library is not alone in the JVM process and other code will want regular SSLContext instances. That leaves you with the only option of specifying the provider explicitly when you create the SSLContext instance in Kafka. That would work, as long as your users don't mess things up with the very common configuration approaches above. A JCE SSLContext provider is intended to be a mechanism to replace the SSLContext implementation. Our purpose is to customize the configuration, not to replace it. This becomes hard to do when your only chance is at creation time. Kafka then does its thing and you have no way to modify that behavior in Kafka. You no longer support many legitimate use cases. The final blow is the need to sign JCE providers using a certificate signed by Oracle's JCE Code Signing Certification Authority. https://www.oracle.com/technetwork/java/javase/tech/getcodesigningcertificate-361306.html JCE will refuse to load your provider if it is not signed. Getting the certificate is a pain and it takes time. You also have to worry about the certificate expiration date. There are JVMs that don't require signed JCE providers, but you cannot limit Kafka to just those JVMs. -----Original Message----- From: Maulin Vasavada [mailto:maulin.vasav...@gmail.com] Sent: Friday, October 4, 2019 5:31 PM To: dev@kafka.apache.org Subject: Re: [DISCUSS] KIP-519: Make SSL context/engine configuration extensible In other words, Kafka doesn't necessarily need to derive another interface/mechanism to make SSLEngine pluggable. That interface/mechanism exists in Java with Security Provider's SSLContext Algorithms. Ref-1: https://docs.oracle.com/javase/9/docs/specs/security/standard-names.html#sslcontext-algorithms Ref-2: https://github.com/bcgit/bc-java/blob/master/tls/src/main/java/org/bouncycastle/jsse/provider/BouncyCastleJsseProvider.java#L193 About the " whole world chooses to make the javax.net.ssl.SSLSocketFactory pluggable" I found the official documentation reinforcing my point I made above, "The javax.net.ssl.SSLSocket class represents a network socket that encapsulates SSL/TLS support on top of a normal stream socket ( java.net.Socket). Some applications might want to use alternate data transport abstractions (e.g., New-I/O); the javax.net.ssl.SSLEngine class is available to produce and consume SSL/TLS packets." Reference: https://docs.oracle.com/javase/7/docs/technotes/guides/security/overview/jsoverview.html I feel that we have to think about building SSLContext in a pluggable way since that is the class that takes "key/trust" material and secure-random config and help creates SSLEngine, SocketFactories via the TLS algorithm's provider specified by Security Provider configuration. Thanks Maulin
