RFR JDK-8206925,,Support the certificate_authorities extension

[Sean Mullan]

For the CSR, why did you check the binary and behavioral boxes for 
compatibility risk? Otherwise it looks good, and I added my name as 
Reviewer. I will review the updated webrev later.

Please file and add a link to a docs issue to document the new system 
property.

--Sean

On 5/13/20 5:20 PM, Xuelei Fan wrote:
> 
> On 5/13/2020 2:11 PM, Sean Mullan wrote:
>>>>> 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.
> If it is treated as a hint, then it might be better no have this extension.
> 
> I checked with browsers, the extension is not present in ClientHello. 
> For JDK, I would not expect a lot use of this extension in client side. 
> It is just designed to workaround a few cases, just as you mentioned above.
> 
> Xuelei