On Wed, 27 Apr 2022 00:35:49 GMT, Valerie Peng <[email protected]> wrote:
>> src/java.base/share/classes/java/security/Signature.java line 1015:
>>
>>> 1013: * parameters were not supplied and the underlying signature
>>> implementation
>>> 1014: * can generate the parameter values, it will be returned.
>>> Otherwise,
>>> 1015: * {@code null} is returned.
>>
>> If we cannot guarantee anything but just want to clarify. how about just say
>> "The returned parameters is a combination of user-provided values,
>> implementation default values, and/or random values used by the underlying
>> signature implementation. It can also be {@code null} if there's none."
>>
>> I assume that if a value is necessary but user has not provided one, then
>> there will be a default or a random one.
>
> 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?
-------------
PR: https://git.openjdk.java.net/jdk/pull/8396
