RFR: 8280494: (D)TLS signature schemes [v2]
Jamil Nimeh
jnimeh at openjdk.java.net
Fri Jan 28 15:54:15 UTC 2022
On Fri, 28 Jan 2022 15:44:16 GMT, Sean Mullan <mullan at openjdk.org> wrote:
>> 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?
I asked a similar question about the System property interaction in the CSR and he has some answers there.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7252
More information about the security-dev
mailing list