Contract of the javax.net.ssl.X509KeyManager.chooseClientAlias method

[Bradford Wetmore]

I haven't been following what OpenJDK has been doing recently, but IIRC, 
the original call includes all of the server's requested key types, 
copied directly from the CertificateRequest message.  See:

https://tools.ietf.org/rfcmarkup?doc=2246#section-7.4.4

Have a look at the current code:

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/ssl/CertificateRequest.java

See the T10CertificateRequestMessage(line 
182)/T10CertificateRequestConsumer(346) where the message is read off 
the wire, then is passed to chooseClientAlias(369) after checking for 
duplicates() and whether the algorithm is available.

It's similar but more involved for TLS12.

Brad




On 12/27/2020 1:54 AM, Thomas Fox wrote:
> Hello,
> 
> I have a question regarding the contract of the method javax.net.ssl.X509KeyManager.chooseClientAlias(String[] keyType, Principal[] issuers, Socket socket). This method gets called by SSL code on a client when a SSL connection is opened to a server, the server requests client authentication and the client wants to choose which one of the available keys is used for the authentication.
> The question is whether the SSL code should pass all possible key types in the argument keyType, or should it pass only one (probably the favoured key type???) in the argument keyType?
> The javadoc of the argument says "keyType - the key algorithm type name(s), ordered with the most-preferred key type first.", which leaves a little room to interpretation (is it "all acceptable key algorithm type name(s)" or "a subset of all allowed key algorithm type name(s)"?).
> 
> Background is that the argument keyType passed by the SSL code is different between (A) openjdk 8u272 TLSv1.2 on the one hand and (B) openjdk 8u272 TLSv1.1, openjdk 8u265 TLSv1.1 and openjdk 8u265 TLSv1.2 on the other hand. In the former case (A), ["EC"] is passed as keyType, whereas in the latter case (B), ["RSA", "DSA", "EC"] is passed as key type, with no other changes except from JDK and TLS version. Note that in all cases, at least the key type "RSA" is acceptable as a key type.
> The question is if the behavior (A) is a bug (see [1]), because it does not contain the acceptable key type "RSA" (did not check whether DSA keys are also acceptable).
> 
> One implementation (Apache HttpClient 4.5.13 org.apache.http.conn.ssl.SSLContextBuilder.KeyManagerDelegate, [2]) uses the passed key types to find matching keys (it iterates over the passed key types and asks a delegate KeyManger for aliases for that key type). In case (1) this strategy fails if the keystore only contains a RSA key because RSA keys are never queried, although the RSA key can be used to authenticate to the server.
> If (A) were correct, how could the implementation guess that it can also return a RSA key?
> 
>      Thanks,
>          
>              Thomas Fox
> 
> [1] https://github.com/AdoptOpenJDK/openjdk-support/issues/200
> [2] https://hc.apache.org/httpcomponents-client-ga/httpclient/xref/org/apache/http/conn/ssl/SSLContextBuilder.html#L221
>