Code review request: JDK-8046295 - Support Trusted CA Indication extension

Xuelei Fan xuelei.fan at oracle.com
Fri Jun 9 21:15:13 UTC 2017


I'm OK to use SSLParameters.  Thank you very much for considering a new 
design.

Xuelei

On 6/9/2017 1:10 PM, Martin Balao wrote:
> Hi Xuelei,
> 
> I didn't notice that some of the SSLSocket contructors did not establish 
> the connection, so SSLParameters can be effective for Trusted CA 
> Indication. This was an invalid argument on my side, sorry.
> 
> As for the configuration to enable the extension, it's probably not 
> necessary on the Server side because -as you mentioned- it is mandatory 
> and there is no harm in supporting it. However, it has to be 
> configurable on the Client side because -as we previously discussed- the 
> client may cause a handshake failure if the server does not support the 
> extension. I'd prefer the Client configuring the SSLSocket through 
> SSLParameters instead of a system-wide property -which has even more 
> impact than the TrustManager approach-. Would this work for you?
> 
>  > In JSSE, the benefits pre_agreed option can get by customizing the 
> key/trust manager, so I did not see too much benefits to support this 
> option in JDK
> 
> I understand your point and will remove support for "pre_agreed".
> 
> 
> On Fri, Jun 9, 2017 at 1:37 AM, Xuelei Fan <xuelei.fan at oracle.com 
> <mailto:xuelei.fan at oracle.com>> wrote:
> 
> 
> 
>     On 6/8/2017 8:36 PM, Xuelei Fan wrote:
> 
>         The trusted authorities can be get from client trust manager. 
>         Server can choose the best matching of server certificate of the
>         client requested trusted authorities.
> 
>     >
>     I missed the point that the key manager need to know the client
>     requested trusted authorities for the choosing.  So may need a new
>     SSLSession attribute (See similar method in ExtendedSSLSession).
> 
>     Xuelei
> 
> 
> 
> Yes, an attribute on SSLSession may do the job (both when Key Manager 
> receives a SSLSocket and a SSLEngine).
> 
> Kind regards,
> Martin.-
> 



More information about the security-dev mailing list