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

Martin Balao mbalao at redhat.com
Wed Jun 7 13:37:53 UTC 2017


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170607/c970cea9/attachment.htm>


More information about the security-dev mailing list