RFR: 8311596: Add separate system properties for TLS server and client for maximum chain length [v8]

[Sean Mullan]

On Wed, 8 Nov 2023 04:18:24 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> The choice of 8 for the client is mostly based on different processing requirements and use cases for TLS client vs server certificate chains. If we see evidence that 8 is too low, we can always consider adjusting it.
>
> I'm not sure if the number 8 or 10 really make a good difference in practice.  No matter 8 or 10,  if customers need lower value, they can always consider adjusting it.  My concern is mainly about compatibility issues.  If you want to keep the behavior changes, as there is potential compatibility issue, please feel free to describe the behavior change in release note and CSR if you would like.

Good point - the CSR and RN could have been a bit more specific about the compatibility effect of changing the default from 10 to 8, so we will update that. Note that the CertPathBuilder default max path length [is 5 non-self-issued intermediate CA certificates](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/security/cert/PKIXBuilderParameters.html#setMaxPathLength(int)), so even a lower value of 8 should have low risk as rigid TLS cert chains greater than 6 certs (where the 6th cert is the end entity cert which is not affected by the CertPathBuilder limit) on the wire will already be rejected. The additional certs permitted in the wire format is more for including a few more additional certs that might help build a valid path when there is more than one possible chain that a server might accept, which sometimes happens.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1388466148