RFR JDK-8206925,,Support the certificate_authorities extension

[Sean Mullan]

On 5/15/20 1:22 AM, Xuelei Fan wrote:
> 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.

By negative test case, do you mean trying to exceed the maximum number 
of CAs? I agree that would be a good test to add, as we may or may not 
exceed that number some day, but it would be good to know when/if we do.

--Sean

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