RFR JDK-8206925,,Support the certificate_authorities extension

[Sean Mullan]

On 5/13/20 4:16 PM, Xuelei Fan wrote:
> 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.

I see. Out of curiosity, have you checked how other implementations 
handle this extension? For web browsers, they typically give the user 
the option of proceeding if the server certificate is not trusted. Seems 
to be a bit of a configuration dilemma as you may want this extension 
enabled for certain sites that have multiple certificates, but not as a 
general default because then you wouldn't be able to connect to 
untrusted sites (at your own risk of course). I wonder if it would have 
been better for the RFC to allow the server to treat this extension more 
as a hint, and still return its chain if an acceptable certificate could 
not be found.

--Sean