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

[Xuelei Fan]

Hi Martin,

Thanks for the contribution of the extension implementation.

Do you know the real requirements or user cases for this extension?


There is a vague point for this extension (Section 6, RFC 6066):

    Servers that receive a client hello containing the "trusted_ca_keys"
    extension MAY use the information contained in the extension to guide
    their selection of an appropriate certificate chain to return to the
    client.

For better interop, a vendor may not use this extension if no 
appropriate certificate matching the trusted CA indication.  This could 
make the benefits of this extension discounted a lot.

I have some concerns about the design:
1. The trust manager and key manager should be immutable, otherwise 
there are multiple threading issues.  It implies that the set methods 
should not be used for the trust/key managers.

2. The trusted ca indication is connection-oriented attribute, while 
trust/key managers are context wild configuration.  So it may be not the 
right place to configure the trusted ca indication in trust/key manager. 
  For example, every connection may have its own pre-agreed indication. 
While the pre-agreed configuration in key manager means all connections 
in the context have the same pre-agreed indication.

3. In the implementation, if the extension is enabled, the client will 
use all trusted certificates as the trusted ca indication.  As all 
trusted CA are indicated, the extension is actually redundant.  Use it 
or not, no impact on the final handshaking result.  I would think it 
twice to use this extension if there is no significant benefits.

Thanks & Regards,
Xuelei

On 6/7/2017 6:37 AM, Martin Balao wrote:
> Hi,
> 
> 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].
> 
> Webrev (jdk10 jdk10+10 based):
> 
>   * 
> http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-8046295/webrev.00/ 
> (browse online)
>   * 
> http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-8046295/webrev.00/8046295.webrev.00.zip 
> (zip download)
> 
> 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.
> 
> Client side
> 
>   * The extension can be enabled by invoking 'setUseTrustedCAIndication' 
> method on the 'X509TrustManager' instance used for establishing a TLS 
> channel.
>   * 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.
>    * 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.
> 
> Server side
> 
>   * The extension is always enabled on the server side.
>   * 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.
>   * A certificate chain on a 'X509KeyManager' instance can be set as 
> 'pre-agreed' trusted (see RFC 6066) invoking the 
> 'setPreAgreedCertificate' method
>   * This is the procedure through which the server chooses a certificate:
>    * Cipher suites iterated as usual (in preferred order)
>    * If the client has sent Trusted CA Indication data elements:
>     * All the certificate chains for the chosen cipher suite algorithm 
> are retrieved from the 'X509KeyManager' instance and iterated
>      * For each certificate on a chain (starting from root):
>       * For each Trusted CA Indication data element:
>        * 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.
>        * 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.
>   * 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.
>   * SHA-1 certificate hash, SHA-1 key hash, Distinguished Name and 
> pre-agreed methods specified by RFC 6066 are supported.
> Test cases implemented for both client and server sides.
> 
> Thanks in advanced,
> Martin Balao.-
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8046295
> [2] - http://www.oracle.com/technetwork/community/oca-486395.html#r
> [3] - https://tools.ietf.org/html/rfc6066#page-12