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
