RFR JDK-8206925,,Support the certificate_authorities extension

[Sean Mullan]

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.

> 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?

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?

--Sean