On Wed, 27 Apr 2022 22:54:47 GMT, Valerie Peng <[email protected]> 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
