On Fri, 13 May 2022 14:35:56 GMT, Sean Mullan <[email protected]> wrote:
>> Hmm, would it fall under the "Otherwise, null is returned"? If not, perhaps
>> we can add back the part about returning AlgorithmParameters as below:
>>
>> **If the underlying signature implementation supports returning the
>> parameters as {@code AlgorithmParameters},** 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 scheme. If the required parameters
>> were not supplied and can be generated by the signature, the generated
>> parameters are returned. Otherwise, {@code null} is returned.
>
> I think it is a special case that should be specified. Theoretically, it
> could also occur if params were not supplied by the caller, but the
> implementation generated parameters and then could not return them as
> AlgorithmParameters. I think the underlying issue is that not all Signature
> algorithms should be required to support an encoded form of the parameters.
>
> It is hard to fit all of these cases in a couple of sentences. I would be
> more inclined to add something like the following after the two sentences you
> currently have: "However, if the underlying implementation does not support
> returning the parameters as `AlgorithmParameters`, `null` is always returned."
Yes, I agree that it's a special case as the convention is to define the
parameter spec class based on the ASN.1 structure. I like your suggestion
better also. Will update using it.
-------------
PR: https://git.openjdk.java.net/jdk/pull/8396
