<div dir="ltr"><div>Hi, </div><div><br></div><div>I'd like to propose a patch for bug ID JDK-8046295 - Support Trusted CA Indication extension [1] and ask for reviews. I have the OCA signed since I'm a Red Hat employee and this is part of my work [2].</div><div><br></div><div>Webrev (jdk10 jdk10+10 based):</div><div><br></div><div> * <a href="http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-8046295/webrev.00/">http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-8046295/webrev.00/</a> (browse online)</div><div> * <a href="http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-8046295/webrev.00/8046295.webrev.00.zip">http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-8046295/webrev.00/8046295.webrev.00.zip</a> (zip download)</div><div><br></div><div>Trusted CA Indication TLS extension (for TLS v1.2+) has been implemented on both client and server sides, according to RFC 6066 [3]. Implementation assumes the use of X.509 certificates.</div><div><br></div><div>Client side</div><div><br></div><div> * The extension can be enabled by invoking 'setUseTrustedCAIndication' method on the 'X509TrustManager' instance used for establishing a TLS channel.</div><div> * When enabled, a SHA-1 hash for each certificate managed by the TrustManager instance is sent to the server as a "Trusted CA Indication" data element. This happens during the Client Hello stage of the TLS Handshake.</div><div>  * Note: SHA-1 key hash, Distinguished Name and pre-agreed methods specified by RFC 6066 to identify a certificate were not implemented on the client side.</div><div><br></div><div>Server side</div><div><br></div><div> * The extension is always enabled on the server side.</div><div> * When a client sends Trusted CA Indication data elements during the Client Hello stage (TLS Handshake), the server tries to choose a certificate from its 'X509KeyManager' instance based on that information. If a certificate is not found, the TLS channel cannot be established.</div><div> * A certificate chain on a 'X509KeyManager' instance can be set as 'pre-agreed' trusted (see RFC 6066) invoking the 'setPreAgreedCertificate' method</div><div> * This is the procedure through which the server chooses a certificate:</div><div>  * Cipher suites iterated as usual (in preferred order)</div><div>  * If the client has sent Trusted CA Indication data elements: </div><div>   * All the certificate chains for the chosen cipher suite algorithm are retrieved from the 'X509KeyManager' instance and iterated</div><div>    * For each certificate on a chain (starting from root):</div><div>     * For each Trusted CA Indication data element:</div><div>      * If there is a match between the Trusted CA Indication data element and the certificate in the server's chain, the certificate chain is chosen.</div><div>      * If Trusted CA Indication data element is of "pre-agreed" type and the certificate chain was set as "pre-agreed", the certificate chain is chosen.</div><div> * As a consequence of the previous procedure, a client may trust in an intermediate certificate and the server will be able to choose a certificate chain that contains that intermediate certificate. </div><div> * SHA-1 certificate hash, SHA-1 key hash, Distinguished Name and pre-agreed methods specified by RFC 6066 are supported.</div><div>  </div><div>Test cases implemented for both client and server sides.</div><div><br></div><div>Thanks in advanced,</div><div>Martin Balao.-</div><div><br></div><div>--</div><div>[1] - <a href="https://bugs.openjdk.java.net/browse/JDK-8046295">https://bugs.openjdk.java.net/browse/JDK-8046295</a></div><div>[2] - <a href="http://www.oracle.com/technetwork/community/oca-486395.html#r">http://www.oracle.com/technetwork/community/oca-486395.html#r</a></div><div>[3] - <a href="https://tools.ietf.org/html/rfc6066#page-12">https://tools.ietf.org/html/rfc6066#page-12</a></div></div>