On Wed, 27 Apr 2022 15:10:42 GMT, Weijun Wang <wei...@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
