RFR: 8280494: (D)TLS signature schemes [v9]

[Xue-Lei Andrew Fan]

On Thu, 3 Feb 2022 21:30:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > > On a related issue, have you given any thought as to what the behavior should be if a 3rd-party JSSE provider is not updated to support these new methods? I don't know of a good way to address that since the API is not part of the provider implementation. We need a way to query what parameters a given provider supports, I think.
> > 
> > 
> > It's a good question. A 3rd party provider need to support to the new APIs. Otherwise, the spec does not really work except to use the default values. It might be overweighted if the Java SE API has to detect the implementation details.
> 
> Fair point. However, I think then we have to make some changes to the specification wording that state that these new methods depend on support from the underlying provider. In other words something like `SSLParameters.setSignatureSchemes(new String[] {"ecdsa_secp521r1_sha512"})` could be silently ignored if the provider doesn't support the new method. It's unfortunate because a developer may miss this point or it may go undetected, whereas throwing an `UnsupportedOperationException` would probably be detected (but which won't work for this API). I do note that previous methods we have added to SSLParameters have probably had this same issue. But I think we should try to address it better with these methods. I'll suggest some wording changes.
> 
> To help reduce this potential issue, we can make sure we mention this issue in the release notes, and encourage 3rd party providers to add support for these methods when they add support for JDK 18.
> 
> Open to other ideas though.

Good points.  I will try to add an apiNote.

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

PR: https://git.openjdk.java.net/jdk/pull/7252