RFR JDK-8206925,,Support the certificate_authorities extension

[Xuelei Fan]

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