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

[Weijun Wang]

On Wed, 27 Apr 2022 22:54:47 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> 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?
>
> Right, the user-supplied values takes precedence and provider-specific default/random values should just be supplemental.
> 
> As for EdDSA, looks like the prehash and context are only in RFC 8032 and NOT RFC 8410.  caller has to pass these settings/values to the other entity through some other means since the getParameters() return null as there is no ASN.1 definition for the parameters. Looks like these values are packaged into a parameter spec and passed into the underlying EdDSA signature implementation in order to fit into existing API without adding new algorithm specific APIs.

So, "the underlying signature implementation supports returning the parameters as {@code AlgorithmParameters}" is quite necessary. Xuelei's suggestion is quite good, just change the last "and" to "or".

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

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