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

[Valerie Peng]

On Wed, 27 Apr 2022 15:10:42 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> 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?

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.

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

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