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
