RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v2]

Weijun Wang weijun at openjdk.java.net
Wed Apr 27 15:13:43 UTC 2022


On Wed, 27 Apr 2022 00:35:49 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/Signature.java line 1015:
>> 
>>> 1013:      * parameters were not supplied and the underlying signature implementation
>>> 1014:      * can generate the parameter values, it will be returned. Otherwise,
>>> 1015:      * {@code null} is returned.
>> 
>> If we cannot guarantee anything but just want to clarify. how about just say "The returned parameters is a combination of user-provided values, implementation default values, and/or random values used by the underlying signature implementation. It can also be {@code null} if there's none."
>> 
>> I assume that if a value is necessary but user has not provided one, then there will be a default or a random one.
>
> I searched about "and/or" and it is said that "or" covers "and". So, "and/or" should just be "or".
> 
> I am on the fence for requiring provider to generate default parameters (using provider-specific or random values). Could there be scenarios where users are required to supply parameters? 
> That aside, this javadoc is lastly updated by JDK-8243424. It seems that JDK's EdDSA signature impl has some interesting usage of AlgorithmParameterSpec which this javadoc has to cover/allow.

RSASSA-PSS always requires a user-provided params.

I think one thing we can guarantee is that the default/random values generated by the impl will never overwrite the user-provided ones, they will only be supplemented. Also, I think the real usage of this method is that the result -- after converting to a spec -- can be set on the verify side and the verification should succeed.

I don't quite understand EdDSA. Looks like the params is not stored along with the signature in the algorithm identifier. I also haven't found different OIDs defined when prehash or context is used. How does the verifier know this kind of flavor settings?

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

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



More information about the security-dev mailing list