RFR JDK-8206925,,Support the certificate_authorities extension

[Xuelei Fan]

Alexey has some good point about the size limit of the extension.  I 
added more comments about the compatibility impact and interop impact 
when there is too much CAs to meet the size limits in CSR, source code 
and release notes.

New webrev: https://bugs.openjdk.java.net/browse/JDK-8244460

I have not had a chance to add a negative test case yet.

On 5/14/2020 1:38 PM, Sean Mullan wrote:
> For the CSR, why did you check the binary and behavioral boxes for 
> compatibility risk?
I should not check the boxes.  Removed.

Thanks,
Xuelei

> 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