On Wed, 27 Apr 2022 23:02:28 GMT, Weijun Wang <[email protected]> wrote:
>> 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".
I assume you were suggesting this? `"The returned parameters may be the same
that were used to initialize this signature, or may contain additional default
or random parameter values used by the underlying signature implementation.
{https://github.com/code null} is returned if the required parameters were not
supplied and the underlying signature implementation cannot generate the
parameter values."`
But the "the underlying signature implementation supports returning the
parameters as {https://github.com/code AlgorithmParameters}" is necessary.
Strictly speaking, this is somewhat different than the "cannot generate
parameter values" though. Perhaps we should go a bit broader for the last
sentence regarding null return value?
-------------
PR: https://git.openjdk.java.net/jdk/pull/8396
