<div dir="ltr"><div><div>Hi Xuelei,</div><div><br></div><div>The new webrev.01 is ready:</div><div><br></div><div> * <a href="http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_trusted_ca/2017_06_13/8046295.webrev.01/">http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_trusted_ca/2017_06_13/8046295.webrev.01/</a> (browse online)</div><div> * <a href="http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_trusted_ca/2017_06_13/8046295.webrev.01.zip">http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_trusted_ca/2017_06_13/8046295.webrev.01.zip</a> (zip, download)</div><div><br></div><div>The following changes have been implemented since the previous webrev.00:</div><div><br></div><div> * Pre-agreed support removed from server-side</div><div> * Unnecessary overhead and minium benefits for JSSE.</div><div><br></div><div> * Enabling the use of Trusted CA Indication extension for clients through TrustManager objects was reverted. Trusted CA Indication extension can now be enabled through: 1) SSLEngine, 2) SSLSocket, or 3) SSLParameters (which can be applied to both SSLEngine and SSLSocket objects). Trusted CA Indication extension is mandatory for servers.</div><div><br></div><div> * SunX509KeyManagerImpl old key manager ("SunX509" algorithm) is now out of scope. This key manager does not support other TLS extensions as Server Name Indication (SNI), which is far more relevant than Trusted CA Indication. The new X509KeyManagerImpl key manager ("PKIX" algorithm) is now in scope.</div><div><br></div><div> * Client requested indications are now an ExtendedSSLSession attribute. ServerHandshaker gets the information from the Client Hello message (now parsed by TrustedCAIndicationExtension class instead of TrustedAuthorityIndicator) and sets it in the ExtendedSSLSession (SSLSessionImpl object). The key manager (i.e.: X509KeyManagerImpl), when choosing a server alias, may now get the information from the ExtendedSSLSession object and guide the certificate selection based on it.</div><div> * In order to allow multiple key managers to use Trusted Authority Indicators information and to allow multiple Trusted Authority Indicators implementations, TrustedAuthorityIndicator has now been split in an abstract class (TrustedAuthorityIndicator, located in javax.net.ssl) and an implementation class (TrustedAuthorityIndicatorImpl, located in sun.security.ssl). No coupling was added between javax.net.ssl and sun.security.ssl packages.</div><div><br></div><div> * Documentation extended and improved.</div><div> </div><div> * Test cases (server and client) updated to reflect the new interface and supported key manager.</div></div><div><br></div><div>Look forward to your new review!</div><div><br></div><div>Kind regards,</div><div>Martin.-</div><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 9, 2017 at 6:15 PM, Xuelei Fan <span dir="ltr"><<a href="mailto:xuelei.fan@oracle.com" target="_blank">xuelei.fan@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm OK to use SSLParameters. Thank you very much for considering a new design.<span class="HOEnZb"><font color="#888888"><br>
<br>
Xuelei</font></span><span class=""><br>
<br>
On 6/9/2017 1:10 PM, Martin Balao wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
Hi Xuelei,<br>
<br>
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.<br>
<br>
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?<br>
<br>
> 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<br>
<br>
I understand your point and will remove support for "pre_agreed".<br>
<br>
<br></span><span class="">
On Fri, Jun 9, 2017 at 1:37 AM, Xuelei Fan <<a href="mailto:xuelei.fan@oracle.com" target="_blank">xuelei.fan@oracle.com</a> <mailto:<a href="mailto:xuelei.fan@oracle.com" target="_blank">xuelei.fan@oracle.com</a>><wbr>> wrote:<br>
<br>
<br>
<br>
On 6/8/2017 8:36 PM, Xuelei Fan wrote:<br>
<br>
The trusted authorities can be get from client trust manager. Server can choose the best matching of server certificate of the<br>
client requested trusted authorities.<br>
<br>
><br>
I missed the point that the key manager need to know the client<br>
requested trusted authorities for the choosing. So may need a new<br>
SSLSession attribute (See similar method in ExtendedSSLSession).<br>
<br>
Xuelei<br>
<br>
<br>
<br>
Yes, an attribute on SSLSession may do the job (both when Key Manager receives a SSLSocket and a SSLEngine).<br>
<br>
Kind regards,<br>
Martin.-<br>
<br>
</span></blockquote>
</blockquote></div><br></div></div>