RFR: 8280494: (D)TLS signature schemes [v2]
Sean Mullan
mullan at openjdk.java.net
Fri Jan 28 15:48:12 UTC 2022
On Fri, 28 Jan 2022 15:17:28 GMT, Sean Mullan <mullan at openjdk.org> wrote:
>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Copyright correction
>
> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 710:
>
>> 708: * Signature Schemes</a> section of the Java Cryptography
>> 709: * Architecture Standard Algorithm Name Documentation, and may also
>> 710: * include other signature schemes that the provider supports.
>
> There doesn't seem to be anything preventing a user from setting a bogus signature scheme (ex: named "foo") - which is neither a standard name or a provider specific name.
> I think the method may be too tightly specified, and you should make this more general and not put any constraints on the names of the signature schemes. (Although we should still link to the specification for a list of standard names).
>
> It would be useful to explain when this method returns pre-populated scheme names as supported by the underlying provider and when it may return an empty list.
You should also define the interaction with the system properties (probably as an @implNote). Does `getSignatureSchemes` ever return the value of the system properties? Does the `setSignatureSchemes` API always override the properties even if it is called by the provider?
-------------
PR: https://git.openjdk.java.net/jdk/pull/7252
More information about the security-dev
mailing list