Summary
-------

Calling `Signature::getParameters` on a ECDSA signature object will always return `null`, even if an earlier `setParameter` method is called on this object.

Problem
-------

After a signature is calculated, the signer usually encodes 3 pieces of information into an application-defined output so that the receiver can verify it properly. They are:

1. The signature algorithm, emitted by `Signature::getAlgorithm`.
2. Parameters for this algorithm (optional), emitted by `Signature::getParameters`.
3. The signature bytes, emitted by `Signature::sign`.

In the current implementation of ECDSA, `getParameters()` returns a non-null object if `setParameter` was previously called.

However, according to the ECDSA signature scheme for X.509 at [RFC 5758 Section 3.2][1]: 

> When the ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with-SHA384, or 
   ecdsa-with-SHA512 algorithm identifier appears in the algorithm field 
   as an AlgorithmIdentifier, the encoding **MUST omit the parameters 
   field**.

This means our ECDSA implementation is not compliant.

We started allowing `setParameter()` to be called in ECDSA in the bug fix for JDK-8225745. It's about a customer certificate that contains parameters for an ECDSA signature (in fact, it's a duplicate copy of parameters for the EC key). When verifying the signature, the parameters are read and passed into `setParameter()`. For symmetric reasons, we allowed `getParameters` returning something in the same code change.

In fact, there is a bug in the `getParameters` implementation. The algorithm of the returned `AlgorithmParameters` object is not an ECDSA signature algorithm but an EC key algorithm. If this `AlgorithmParameters` object is encoded into a certificate it will be an invalid certificate and not recognized by either Java or other tools (Ex: OpenSSL).

Solution
--------

According to RFC 5758, the customer certificate above should have been treated as invalid and rejected. Now that we have accepted it since JDK 13 and there might be other similar certificates out there, for compatibility reason, we decide to keep this behavior so calling `setParameter` is still allowed on an ECDSA signature object. While we are lax in reading such certificates, we should not create certificates that contains the invalid parameters, i.e. `getParameters()` will always return null for an ECDSA signature.

Specification
-------------

This is an implementation detail for the ECDSA signature by the SunEC security provider. There is no specification change.

  [1]: https://datatracker.ietf.org/doc/html/rfc5758#section-3.2