RFR JDK-8206925,,Support the certificate_authorities extension
Sean Mullan
sean.mullan at oracle.com
Fri May 15 12:27:30 UTC 2020
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
More information about the security-dev
mailing list