On Wed, 27 Apr 2022 23:02:28 GMT, Weijun Wang <wei...@openjdk.org> 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