On 5/22/20 6:38 PM, Xuelei Fan wrote:
On 5/22/2020 11:17 AM, Sean Mullan wrote:
On 5/22/20 1:55 PM, Xuelei Fan wrote:
* test/jdk/sun/security/ssl/X509TrustManagerImpl/TooMuchCAs.java
Will this test FAIL if we ever exceed the maximum number of CAs? I
think it is important that it does FAIL, as the extension is
effectively not working anymore and could cause compatibility
issues. I even think we would need to try to think of some way to
fix it, either by seeing if some CAs could be excluded - not really
sure, hopefully it won't ever happen but we would want to know about
it in advance.
Alexey (from azul) and I discussed the idea to control the number of
CAs. However, there are still some issues in practice.
"If the certificate authorities can not be fully listed, it cannot be
used to indicate the peer certificate selection accuracy. For
example, client support A, B and C, and is only able to indicate A
and B. If the server supports C, the connection cannot be
established with this extension. This is not the expected behavior.
Maybe, it is no worse than without this extension. "
It looks like safer that the extension is not used if the size exceed
the limit, at least there ARE less compatibility issues. I have a
note in the CSR and release note for the behaviors.
The test case, TooMuchCAs, is used to make sure the connection can be
established when the CAs size exceed the limit (no extension used).
Sure, I agree that is the best behavior. I guess my point is that if
we ever really exceed the maximum number of CAs in the cacerts
keystore, it would be good to have a test that will fail because of
that. Minimally, this would allow us to publish a release note warning
users that the CA extension will no longer work unless some roots are
removed.
Good point. It is useful to have a test case to check the size limit of
the cacert keystore. A new test case, CacertsLimit.java, is added. The
same webrev URL is used:
http://cr.openjdk.java.net/~xuelei/8206925/webrev.05/
71 "certificate_authorities extension can be
used " +
typo: s/can/cannot/
Looks good otherwise.
--Sean
