Bug 1506826

Summary: org.mozilla.jss.pkix.cms.SignerInfo incorrectly producing signatures (especially for EC)
Product: Red Hat Enterprise Linux 7 Reporter: Matthew Harmsen <mharmsen>
Component: jssAssignee: Christina Fu <cfu>
Status: CLOSED ERRATA QA Contact: ipa-qe <ipa-qe>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.5CC: aakkiang, akahat, cfu, david.k.stutzman2.ctr, edewata, elio.maldonado.batiz, extras-qa, kwright, lmiksik, mharmsen, nkinder, rcritten, rmeggins
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: jss-4.4.0-11.el7 Doc Type: Bug Fix
Doc Text:
The bug fix fixes the OID that goes into the signatureAlgorithm field of the SignerInfo class as well as passing the full signature algorithm to the Signature context to generate the signature using the proper algorithm. With this patch, if one passes SignatureAlgorithm.RSASignatureWithSHA256Digest in the constructor one will now get sha256WithRSAEncryption (1 2 840 113549 1 1 11) in the signatureAlgorithm field.
 Story Points: ---
Clone Of: 1506825 Environment:
Last Closed: 2018-04-10 17:56:52 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1506825    
Bug Blocks:    

Description Matthew Harmsen 2017-10-26 21:54:15 UTC 
+++ This bug was initially created as a clone of Bug #1506825 +++

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.
Comment 2 Matthew Harmsen 2017-10-27 00:16:10 UTC 
changeset:   2207:b1a3c3cc6b3584948d251d3bfcfe6630d8970db5
tag:         tip
phase:       public
parent:      2206:252c10f448971b7ae087bde259505abd5dc5a03a
parent:      -1:0000000000000000000000000000000000000000
manifest:    2006:7b25ef6eb73049be7b320e796e01bf04b6dfd257
user:        David Stutzman david.konrad.stutzman.mil
date:        Thu Oct 26 16:59:06 2017 -0700
files:       org/mozilla/jss/pkix/cms/SignerInfo.java
extra:       amend_source=9024dcb9deab76bd7e28adecbe54d65af90751e8
extra:       branch=default
description:
Bugzilla.mozilla 1409867 org.mozilla.jss.pkix.cms.SignerInfo incorrectly producing signatures (especially for EC)

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.
With this patch, if one passes SignatureAlgorithm.RSASignatureWithSHA256Digest in the constructor one will now get sha256WithRSAEncryption (1 2 840 113549 1 1 11) in the signatureAlgorithm field.

cfu checking in for dstutzman
Comment 3 Christina Fu 2017-10-27 18:39:27 UTC 
Test instruction:

Follow instruction here:
https://pki.fedoraproject.org/wiki/PKI_10.4_CMC_Feature_Update_(RFC5272)#Examples_.28User_Certificates_-EC.29
through the following step:
run CMCRequest to generate a user-signed CMC request.

The resulting cmc.p10-ec2.req at the end of that CMCRequest step is what you want to examine.
There may be other ways to do it, but this was what I did:
dumpasn1 -a -d -v -l cmc.p10-ec2.req > cmc.p10-ec2.req.out

I then look at cmc.p10-ec2.req.out
With this patch, I could see:
2210   12: . . . . . SEQUENCE {
    <06 08>
2212    8: . . . . . . OBJECT IDENTIFIER ecdsaWithSHA256 (1 2 840 10045 4 3 2)
         : . . . . . . . (ANSI X9.62 ECDSA algorithm with SHA256)
    <05 00>
2222    0: . . . . . . NULL
         : . . . . . . }
    <04 47>
2224   71: . . . . . OCTET STRING, encapsulates {
    <30 45>
2226   69: . . . . . . SEQUENCE {
    <02 20>
2228   32: . . . . . . . INTEGER
         : . . . . . . . . 77 43 EA 91 19 B0 9E B9    wC......
         : . . . . . . . . BA DA 60 32 04 92 5A 79    ..`2..Zy
         : . . . . . . . . CD A2 63 57 73 2C E9 14    ..cWs,..
         : . . . . . . . . 5F 1F C4 0A 37 3A 0D FD
    <02 21>
2262   33: . . . . . . . INTEGER
         : . . . . . . . . 00 D9 CA 32 62 D3 00 62    ...2b..b
<snip>

Before the patch, I see the following instead:
2212   11: . . . . . SEQUENCE {
    <06 07>
2214    7: . . . . . . OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
         : . . . . . . . (ANSI X9.62 public key type)
    <05 00>
2223    0: . . . . . . NULL
         : . . . . . . }
    <04 40>
2225   64: . . . . . OCTET STRING   
         : . . . . . . 42 4F CE 34 12 E7 A9 F5    BO.4....
         : . . . . . . 8A BA 7B 95 AB EC 66 BA    ..{...f.

You could try similar steps with RSA.
Comment 7 Christina Fu 2018-01-11 23:11:16 UTC 
pushed.

https://bugzilla.mozilla.org/show_bug.cgi?id=1409867#c12
Comment 8 Amol K 2018-01-31 07:41:02 UTC 
Hi,

I tested this bug on 10.5.1-6.el7 version. After examine CMCRequest I got an expected output.

SEQUENCE includes INTEGER then hex data. 

For EC Request
```
 232    8: . . . . . . . . . . . OBJECT IDENTIFIER
         : . . . . . . . . . . . . ecdsaWithSHA256 (1 2 840 10045 4 3 2)
         : . . . . . . . . . . . . (ANSI X9.62 ECDSA algorithm with SHA256)
    <05 00> 
 242    0: . . . . . . . . . . . NULL
         : . . . . . . . . . . . } 
    <03 47> 
 244   71: . . . . . . . . . . BIT STRING, encapsulates {
    <30 44> 
 247   68: . . . . . . . . . . . SEQUENCE {
    <02 20> 
 249   32: . . . . . . . . . . . . INTEGER    
         : . . . . . . . . . . . . . 4B 99 94 7F A0 EC A9 FD    K.......
         : . . . . . . . . . . . . . 8F A0 F1 2F DB 74 08 6A    .../.t.j
         : . . . . . . . . . . . . . 17 2E F1 C0 1D E6 1D 29    .......)
         : . . . . . . . . . . . . . F8 E1 A6 EE 43 53 52 7B    
    <02 20> 
 283   32: . . . . . . . . . . . . INTEGER    
         : . . . . . . . . . . . . . 4A E8 89 7E E5 B4 54 41    J..~..TA
         : . . . . . . . . . . . . . F5 E0 45 5C A1 9A 42 0A    ..E\..B.
         : . . . . . . . . . . . . . 17 49 86 28 DD 8F 02 E5    .I.(....
         : . . . . . . . . . . . . . 2D B2 78 9A 6F B5 5E 7C    
         : . . . . . . . . . . . . } 
         : . . . . . . . . . . . } 
```

For RSA Request:
```
 148    9: . . . . . . . . . . . . . OBJECT IDENTIFIER
         : . . . . . . . . . . . . . . rsaEncryption (1 2 840 113549 1 1 1)
         : . . . . . . . . . . . . . . (PKCS #1) 
    <05 00> 
 159    0: . . . . . . . . . . . . . NULL
         : . . . . . . . . . . . . . } 
    <03 82 01 0F> 
 161  271: . . . . . . . . . . . . BIT STRING, encapsulates {
    <30 82 01 0A> 
 166  266: . . . . . . . . . . . . . SEQUENCE {
    <02 82 01 01> 
 170  257: . . . . . . . . . . . . . . INTEGER    
         : . . . . . . . . . . . . . . . 00 D6 36 ED 1C 90 75 32    ..6...u2
         : . . . . . . . . . . . . . . . 3C BA 71 EC 1A 3E DD B0    <.q..>..
         : . . . . . . . . . . . . . . . FE A7 F8 C5 A3 4A F5 D2    .....J..
         : . . . . . . . . . . . . . . . 6B 40 1A 01 C5 F6 AB EF    k@......
         : . . . . . . . . . . . . . . . 1B C8 ED 90 B0 A7 B2 08    ........
         : . . . . . . . . . . . . . . . 6D 90 23 F9 8C 1A D1 5D    m.#....]
         : . . . . . . . . . . . . . . . AE 35 59 D2 A1 2F C2 6D    .5Y../.m
         : . . . . . . . . . . . . . . . 9E D1 26 6B 4B 3C C9 79    ..&kK<.y
         : . . . . . . . . . . . . . . . 03 36 12 17 22 65 67 09    .6.."eg.
         : . . . . . . . . . . . . . . . 8D 2B 57 A0 CD B7 90 0C    .+W.....
         : . . . . . . . . . . . . . . . 6B FE B9 05 BA B3 46 98    k.....F.
         : . . . . . . . . . . . . . . . D5 46 80 5B 74 95 61 7F    .F.[t.a.
         : . . . . . . . . . . . . . . . E1 B4 01 19 71 21 2D 4D    ....q!-M
         : . . . . . . . . . . . . . . . 9F F7 7F 6D C4 E9 3A F5    ...m..:.
         : . . . . . . . . . . . . . . . 56 78 9C 72 7A 38 74 FC    Vx.rz8t.
         : . . . . . . . . . . . . . . . DB 12 6E 24 B2 E2 CB E5    ..n$....
         : . . . . . . . . . . . . . . . 44 7D EF D1 8E 3F 9D 20    D}...?. 
         : . . . . . . . . . . . . . . . B1 EE 6A 6D 8A 15 7A 55    ..jm..zU
         : . . . . . . . . . . . . . . . 9A 17 46 28 99 E1 88 15    ..F(....
         : . . . . . . . . . . . . . . . F2 67 C6 47 C8 9F B4 E5    .g.G....
         : . . . . . . . . . . . . . . . 65 E4 15 8F 7F 23 D5 0A    e....#..
         : . . . . . . . . . . . . . . . 07 1E A6 3E 56 32 86 2A    ...>V2.*
         : . . . . . . . . . . . . . . . A8 ED D2 7F 9A 5F 0A 2C    ....._.,
         : . . . . . . . . . . . . . . . 59 66 0B 15 E3 B7 96 0A    Yf......
         : . . . . . . . . . . . . . . . 74 CF C1 C4 00 9A B6 AC    t.......
         : . . . . . . . . . . . . . . . 5D 25 77 20 5E 14 04 C7    ]%w ^...
         : . . . . . . . . . . . . . . . 68 1B AE 6F 2B 72 5D 66    h..o+r]f
         : . . . . . . . . . . . . . . . E2 B1 B7 EA 92 49 AE 76    .....I.v
         : . . . . . . . . . . . . . . . E0 09 1A E8 DB F3 BA 29    .......)
         : . . . . . . . . . . . . . . . C6 EE 24 88 D3 AC 62 81    ..$...b.
         : . . . . . . . . . . . . . . . FF 9A F0 3E 57 C0 7F AB    ...>W...
         : . . . . . . . . . . . . . . . 48 A7 C0 8B 7E CE 9A 1D    H...~...
         : . . . . . . . . . . . . . . . 93                         .
    <02 03> 
 431    3: . . . . . . . . . . . . . . INTEGER 65537
         : . . . . . . . . . . . . . . } 
         : . . . . . . . . . . . . . } 
         : . . . . . . . . . . . . } 

```

Verifying the bug.
Comment 11 errata-xmlrpc 2018-04-10 17:56:52 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0958