In https://bugzilla.mozilla.org/show_bug.cgi?id=1409867,
David Stutzman Created attachment 8919888 [details]
SignerInfo-patch.txt

This class appears to generate signatures with a different algorithm and adds the wrong signatureAlgorithm than the user of the class passes into the constructor.

The constructor takes in a SignatureAlgorithm.  One would expect that same algorithm to appear in the signatureAlgorithm field of the SignerInfo.  That is not presently the case.  The signatureAlgorithm field ends up populated with the "raw" key algorithm and the signature is calculated with that same algorithm.

Currently in JSS, the encoding of the signatureAlgorithm and signature fields of a JSS SignerInfo where I passed in SignatureAlgorithm.ECSignatureWithSHA256Digest results in the following:
212  11: . SEQUENCE {
214   7: . . OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
       : . . . (ANSI X9.62 public key type)
223   0: . . NULL
       : . . }
225  64: . OCTET STRING    
       : . . E8 DC 24 7E 51 87 85 87    ..$~Q...
       : . . 96 CA 00 05 E4 FB 58 CC    ......X.
       : . . 8D C4 E4 5F 7D 2B B3 47    ..._}+.G
       : . . 2D ED E5 09 47 F0 F2 55    -...G..U
       : . . C5 5A F6 FA 99 BA D8 66    .Z.....f
       : . . 96 B4 ED F1 0B E2 91 CD    ........
       : . . 6C D8 2C A1 55 50 25 E1    l.,.UP%.
       : . . E4 A9 E5 96 D3 03 D7 19                            
       : . }

whereas it should be the following (this is after applying my patch):
212  12: . SEQUENCE {
214   8: . . OBJECT IDENTIFIER ecdsaWithSHA256 (1 2 840 10045 4 3 2)
       : . . . (ANSI X9.62 ECDSA algorithm with SHA256)
224   0: . . NULL
       : . . }
226  72: . OCTET STRING, encapsulates {
228  70: . . SEQUENCE {
230  33: . . . INTEGER    
       : . . . . 00 F7 7D 41 9A 12 38 99    ..}A..8.
       : . . . . CC 63 81 0A E1 FF A8 ED    .c......
       : . . . . 0B 03 3F AF 38 01 70 59    ..?.8.pY
       : . . . . A7 25 1A 13 C8 50 6F B2    .%...Po.
       : . . . . D6                         .
265  33: . . . INTEGER    
       : . . . . 00 88 83 38 85 A6 6C 54    ...8..lT
       : . . . . 11 B2 BE C4 EB 49 E4 AC    .....I..
       : . . . . A4 A6 51 0D 95 AB BE E5    ..Q.....
       : . . . . 8D 20 2D 25 14 02 5B 33    . -%..[3
       : . . . . 8F                         .
       : . . . }
       : . . }
       : . }

The patch fixes the OID that goes into the signatureAlgorithm field as well as passing the full signature algorithm to the Signature context to generate the signature using the proper algorithm.

According to RFC 5753 (Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)):
   -  signatureAlgorithm contains the signature algorithm identifier
      (see Section 7.1.3): ecdsa-with-SHA1, ecdsa-with-SHA224, ecdsa-
      with-SHA256, ecdsa-with-SHA384, or ecdsa-with-SHA512.  The hash
      algorithm identified in the name of the signature algorithm MUST
      be the same as the digestAlgorithm (e.g., digestAlgorithm is id-
      sha256 therefore signatureAlgorithm is ecdsa-with-SHA256).

   -  signature MUST contain the DER encoding (as an octet string) of a
      value of the ASN.1 type ECDSA-Sig-Value (see Section 7.2).

I also see that this same behavior with RSA signature algorithms where regardless of the signature algorithm that the user passed into the constructor, the encoded signatureAlgorithm will be 1.2.840.113549.1.1.1 (rsaEncryption).

With my patch, If I pass SignatureAlgorithm.RSASignatureWithSHA256Digest in the constructor I will now get sha256WithRSAEncryption (1 2 840 113549 1 1 11) in the signatureAlgorithm field.