Updated webrev: http://cr.openjdk.java.net/~xuelei/8206925/webrev.02/
The CSR and release note were updated accordingly, to use the new system
property.
On 5/13/2020 6:38 AM, Sean Mullan wrote:
On 5/12/20 5:43 PM, Xuelei Fan wrote:
Updated webrev: http://cr.openjdk.java.net/~xuelei/8206925/webrev.01/
On 5/12/2020 12:40 PM, Sean Mullan wrote:
On 5/5/20 2:29 PM, Xuelei Fan wrote:
Hi,
Could I get the following update reviewed?
RFE: https://bugs.openjdk.java.net/browse/JDK-8206925
CSR: https://bugs.openjdk.java.net/browse/JDK-8244441
We have previously used the syntax "enable[Extension]" when naming
system properties that enable optional extensions. Thus, it seems
this name would be more consistent:
"jdk.tls.client.enableCertificateAuthoritiesExtension"
However, it is a bit long, so maybe we could abbreviate it to CA:
"jdk.tls.client.enableCAExtension"
"enableCAExtension" looks fine, but it is not as instinctive as
"indicateCertificateAuthorities".
I think naming consistency is important.
We used to use "enableXXExtension" because normally there is only one
behavior for the extension. However, for the Certificate Authorities
extension, it could be requested by server side to indicate client
cert selection, or by client side to indicate server cert selection.
It is not straightforward to know if "enableCAExtension" means
accepting server request, or produce client request.
But doesn't "jdk.tls.client" mean enable the extension on the client side?
I am not following why the word "indicate" helps better distinguish
between setting the extension on the client or server side.
Okay, updated to use "enableCAExtension" for the property name.
It is not expected to use this extension regularly.
Please let me know if you still prefer to use "enableCAExtension".
Also, it is a bit unfortunate that we have to have a system property
to enable it. Can we not enable it based on whether the configured
X509TrustManager.getAcceptedIssuers returns a non-empty list?
We can do that on server side, but there are compatibility impact on
client behavior if we did it in client side. See #2 in the
"Specification" section.
But doesn't the default JDK PKIX TrustManager throw a fatal exception
and close the connection if the server's certificate cannot be
validated? Could we check if the PKIX TrustManager is being used?
Yes, the trust manager could throw a fatal exception and close the
connection if the trust cannot be established. The fallback mechanism
is implemented in the customized trust manager, that if users accept the
cert, the cert is trusted, and no exception and the handshaking
continued. It is too later to fallback after the connection closed.
If a client wants to accept self-signed or untrusted server
certificates, I would have expected them to have to use a custom
X509TrustManager that allows that, and that getAcceptedIssuers() should
return an empty List. Is that not is what is typically done in practice?
Yes, customized trust manager is used to accept users manually
selection. As the users may also want to accept normal certificate
without manually involved, so getAcceptedIssuers() should respect those
CA as well.
Xuelei