RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1506826 - org.mozilla.jss.pkix.cms.SignerInfo incorrectly producing signatures (especially for EC)
Summary: org.mozilla.jss.pkix.cms.SignerInfo incorrectly producing signatures (especia...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: jss
Version: 7.5
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Christina Fu
QA Contact: ipa-qe
URL:
Whiteboard:
Depends On: 1506825
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-10-26 21:54 UTC by Matthew Harmsen
Modified: 2018-04-10 17:57 UTC (History)
13 users (show)

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.
Clone Of: 1506825
Environment:
Last Closed: 2018-04-10 17:56:52 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Mozilla Foundation 1409867 0 None None None 2017-10-26 21:54:15 UTC
Red Hat Product Errata RHBA-2018:0958 0 None None None 2018-04-10 17:57:58 UTC

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
Note You need to log in before you can comment on or make changes to this bug.