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 1040640 - Incorrect OIDs for SHA2 algorithms
Summary: Incorrect OIDs for SHA2 algorithms
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: jss
Version: 7.0
Hardware: other
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Christina Fu
QA Contact: Asha Akkiangady
URL:
Whiteboard:
: 824624 1040638 (view as bug list)
Depends On: 1040638
Blocks: 530474 1061410 1190302
TreeView+ depends on / blocked
 
Reported: 2013-12-11 18:51 UTC by Nathan Kinder
Modified: 2015-03-05 13:22 UTC (History)
7 users (show)

Fixed In Version: jss-4.2.6-35.el7
Doc Type: Bug Fix
Doc Text:
Clone Of: 1040638
: 1190302 (view as bug list)
Environment:
Last Closed: 2015-03-05 13:22:21 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
This is the same patch provided by jnimeh@gmail.com. (772 bytes, patch)
2014-09-12 22:02 UTC, Christina Fu 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:0521 0 normal SHIPPED_LIVE jss bug fix and enhancement update 2015-03-05 16:32:59 UTC

Description Nathan Kinder 2013-12-11 18:51:04 UTC 
+++ This bug was initially created as a clone of Bug #1040638 +++

+++ This bug was initially created as a clone of Bug #824624 +++

Description of problem:
Verification of the PKCS#7 signed data portion of SCEP CertRep messages issued by the CA have an invalid digestAlgorithm OID in the signerInfo.  The problem appears to be the OID that is given in the digestAlgorithm field of the signerInfo portion of the PKCS#7 signature.  For CertRep messages using MD5 and SHA-1 the OID is correct and matches the single OID in the digestAlgorithms list from the SignedData segment.  In the case of SHA-256 and SHA-512, it appears that the second to the last octet in the two digests (0x2) is missing.  For SHA-256 the OID in the signerInfo is "2.16.840.1.101.3.4.1" (it should be ...3.4.2.1).  For SHA-512 the OID given is "2.16.840.1.101.3.4.3"when it should end "...3.4.2.3"

Version-Release number of selected component (if applicable):
pki-core 9.0.17 and 9.0.19.  The latter was used to generate the messages in the attachment.  Other possibly relevant versions: NSS 3.13.4-2, NSPR 4.9-2, JSS 4.2.6.24

How reproducible: Easily reproducible (I see the issue on every CertRep from the CA using SHA-256 or SHA-512).

Steps to Reproduce:
1. Create a CA and RA using all default options.  Configure the CA to use
   SHA-256 or SHA-512 in CS.cfg
ca.scep.hashAlgorithm=SHA256
or
ca.scep.hashAlgorithm=SHA512

2. Create a pin for the scep client using the RA web interface
3. Use sscep to create a request using the pin
4. Attempt to enroll using "sscep enroll -f sscep.conf"
5. Capture the CertRep message returned by the CA either with wireshark or by turning on the verbose/debug flags in the sscep client.

Note: you may want a version of sscep modified to use sha256 for the request, though I don't think it's necessary.
http://pki.fedoraproject.org/wiki/SCEP_in_Dogtag
See the section "SCEP Request Generation with SHA2"

Actual results:
The signerInfo portion of the CertRep from the CA will have an invalid digest OID.  For SHA-256 the OID in the signerInfo is "2.16.840.1.101.3.4.1".  For SHA-512 the OID in the signerInfo is "2.16.840.1.101.3.4.3"

Expected results:
For SHA-256 the OID in the signerInfo should be "2.16.840.1.101.3.4.2.1"
For SHA-512 the OID in the signerInfo should be "2.16.840.1.101.3.4.2.3"

Additional info:
The workaround for this is to use MD5 or SHA-1 for the digestAlgorithm.
I have attached a zip file with CertRep success (issued cert) and failure messages for SHA-1 (working perfectly), SHA-256 and SHA-512 (both with invalid OIDs).  All CertRep messages are in PEM form.

--- Additional comment from Andrew Wnuk on 2012-05-23 19:33:20 EDT ---

Jamil, Did you rebuild SSCEP with updates requested in http://pki.fedoraproject.org/wiki/SCEP_in_Dogtag#SSCEP_Updates ?

--- Additional comment from Andrew Wnuk on 2012-05-23 19:36:47 EDT ---

Jamil, Did you try the same test against CA (without RA in the middle)?

--- Additional comment from Jamil Nimeh on 2012-05-23 19:40:28 EDT ---

(In reply to comment #1)
> Jamil, Did you rebuild SSCEP with updates requested in
> http://pki.fedoraproject.org/wiki/SCEP_in_Dogtag#SSCEP_Updates ?

Yes, and that appears to be working fine.  When I dump the PKCSReq messages from sscep they are properly formed.(In reply to comment #2)
> Jamil, Did you try the same test against CA (without RA in the middle)?

No, haven't tried that, but I certainly can give that a shot.  I will try that and let you know what I find.

--- Additional comment from Jamil Nimeh on 2012-05-24 01:24:10 EDT ---



--- Additional comment from Jamil Nimeh on 2012-05-24 01:26:03 EDT ---

Hello Andrew,

As you requested, I set up direct-to-ca enrollment with my sscep client.  I could only get CertRep failure messages, but those failure messages show the issue just as well as the success cases.

I made 3 CertRep failure messages, one with each of SHA1/SHA256/SHA512.  In the SHA-1 case, the message verifies correctly with sscep.  In the 256/512 cases it does not.  Once again I see the odd OID in the signerInfo.  I have attached the three PEM files and the CA cert used to do the signing in a zip file.

I know you had some misgivings about this because of sscep and it's known issue with SHA2.  I did some tests with openssl directly, taking sscep out of the picture (other than as a vehicle to drive the SCEP enrollment and make the CA issue a CertRep).

If you try doing this command on the SHA1-signed file you should get this:
> openssl cms -verify -inform PEM -in scep-certrep-sha1-fail.pem -certfile ca.pem -noverify
Verification successful

Note: you need the -noverify or openssl will complain that the PKCS#7 was signed by a self-signed cert.  It doesn't mask the issue as you can see when verifying the SHA256 and SHA512 responses:

> openssl cms -verify -inform PEM -in scep-certrep-sha256-fail.pem -certfile ca.pem -noverify
Verification failure

> openssl cms -verify -inform PEM -in scep-certrep-sha512-fail.pem -certfile ca.pem -noverify
Verification failure

In terms of the message digest calculated and placed in the signerInfo's authenticatedAttributes segment, the hashes for all three are correct.  The reason OpenSSL cannot verify the signature is that it does not know which digest to use.  It relies on the signerInfo's digestAlgorithm OID to tell it what to use.  I believe NSS does also.

If you do "openssl asn1parse -i -in scep-certrep-sha1-fail.pem" you can see how SHA-1 is the one algorithm in the signedData digestAlgorithms field (offset 30).  Continuing down into the signerInfo, SHA-1 is found again (offset 148).

Now look at SHA256.  Things look fine up in the signedData digestAlgorithms (again at offset 30).  But check out the signerInfo's digestAlgorithm field (offset 152).  It's not the same OID.  As I read RFC 2315, the field here has to match one of the algorithms listed up in the digestAlgorithms segment (back up at offset 30).  I got that from section 9.2 of RFC 2315.

The same kind of discrepancy happens with the SHA512 response.

What I have been unable to figure out is why that OID isn't matching.  From looking at the Java code in CRSPKIMessage.java, it has an OID definition for SHA256 and SHA512 and it's correct.  And it certainly looks like it's handing the correct signing algorithm down to JSS when it calls the new SignerInfo constructor in makeSignerInfo().  So I'm left scratching my head...

--- Additional comment from Jamil Nimeh on 2012-07-09 11:50:41 EDT ---

I believe I may have found something:

I was working on a modified version of CMCRevoke and found that when I changed the signing algorithm from the default SHA-1 to SHA-256 I ran into the same oddball OID problems as with SCEP.  I took as many packages out of the classpath as possible to trim it down to a handful of jar files that may be at issue.

I believe that the issue is not with any single jar file, but an interaction between jss 4.2.6 and later versions of NSS.  On a Fedora Core 15 system the latest update delivers:

JSS 4.2.6
NSS 3.13.4

What I did was bring down a compiled jss 4.3 from ftp://ftp.mozilla.org/pub/mozilla.org/security/jss/releases/JSS_4_3_RTM/jss4.jar and changed my run-time classpath variable to point at this jar file rather than the one at /usr/lib64/jss/jss4.java.

Suddenly the signatures on the CMC revocation request came out with the proper OIDs on them!  I have not tried integrating the 4.3 version of jss4.jar with Dogtag servers yet, but I suspect it will make things work there, too.

I would like to know if folks on the Dogtag team feel it is safe to bring in JSS 4.3 (or whatever the latest/greatest JSS is that is still compatible with NSS 3.13.x).

--- Additional comment from Nathan Kinder on 2012-12-10 15:32:53 EST ---

Upstream ticket:
https://fedorahosted.org/pki/ticket/443

--- Additional comment from David Stutzman on 2013-12-11 13:39:48 EST ---

Alluded to by comment 6, this issue also affects the CMC functionality of the CA as CMC responses use CMS SignerInfo structures as well.  

The issue is the constants in DigestAlgorithm class:
DigestAlgorithm.SHA256
DigestAlgorithm.SHA384
DigestAlgorithm.SHA512

In RHEL 6.5 the current version of jss is 4.2.6-24 and it returns the following OIDS:
{2 16 840 1 101 3 4 1}
{2 16 840 1 101 3 4 2}
{2 16 840 1 101 3 4 3}

From JSS 4.3 RTM (from mozilla.org ftp) and up the correct OIDS are returned:
{2 16 840 1 101 3 4 2 1}
{2 16 840 1 101 3 4 2 2}
{2 16 840 1 101 3 4 2 3}
Comment 1 Jamil Nimeh 2013-12-11 18:53:45 UTC 
I've been able to rebuild JSS with the following fix in it and it has been working very well for me for the past few months.  One file/one line fix:

diff -uN --recursive jss-4.2.6.orig/mozilla/security/jss/org/mozilla/jss/asn1/OBJECT_IDENTIFIER.java jss-4.2.6/mozilla/security/jss/org/mozilla/jss/asn1/OBJECT_IDENTIFIER.java
--- jss-4.2.6.orig/mozilla/security/jss/org/mozilla/jss/asn1/OBJECT_IDENTIFIER.java     2004-10-12 16:24:39.000000000 -0700
+++ jss-4.2.6/mozilla/security/jss/org/mozilla/jss/asn1/OBJECT_IDENTIFIER.java 2013-02-20 15:10:08.789342921 -0800
@@ -111,7 +111,7 @@
      * The OID space for FIPS-180-2 SHA256/SHA384/SHA512 standardized algorithms.
      */
     public static final OBJECT_IDENTIFIER HASH_ALGORITHM =
-        new OBJECT_IDENTIFIER( new long[] {2, 16, 840, 1, 101, 3, 4 } );
+        new OBJECT_IDENTIFIER( new long[] {2, 16, 840, 1, 101, 3, 4, 2 } );


     /**
Comment 2 Christina Fu 2013-12-11 23:21:11 UTC 
(In reply to Jamil Nimeh from comment #1)

Thank you Jamil for the contribution. I have taken a look of the fix and it looks good.

 I will put your email down as the contributor in the change log of the official build(s) when it happens. Best regards.
Comment 4 Nathan Kinder 2014-07-21 15:48:35 UTC 
*** Bug 1040638 has been marked as a duplicate of this bug. ***
Comment 5 Christina Fu 2014-09-12 22:02:02 UTC 
Created attachment 937135 [details]
This is the same patch provided by jnimeh.

This patch is now reviewed and tested by myself ready for next build.

Test information for QE :
Note1: There is a bug in CMCRequest: https://fedorahosted.org/pki/ticket/1158 CMCRequest does not support internal token

Note2:This is how I did it; you are free to use other tools/methods):
You might want to do the following exercise on a the CA running with previous JSS build (e.g. jss-4.2.6-33)
* in CS.cfg: ca.signing.defaultSigningAlgorithm=SHA256withRSA
* Generate a CMC request:
  - generate a pkcs10 request
    e.g. PKCS10Client -d . -p <passwd> -o certReq.p10 -n "CN=cfuTest" -a rsa -l 2048
  - generate a CMC request using the resulting pkcs10 request from above:
    e.g. cat p10cmc.conf
numRequests=1

#input: full path for the PKCS10 request or CRMF request,
#the content must be in Base-64 encoded format
#Multiple files are supported. They must be separated by space.
input=certReq.p10

#output: full path for the CMC request in binary format
output=certReq.p10.cmc

#nickname: nickname for agent certificate which will be used
#to sign the CMC full request.
#tokenname=internal
nickname=PKI Administrator for ca host

#dbdir: directory for cert8.db, key3.db and secmod.db
dbdir=./

#password: password for cert8.db which stores the agent
#certificate
password=<replace it with your password>

#format: request format, either pkcs10 or crmf
format=pkcs10

<snip>
    
* use HttpClient to subnmit the CMC request to CA:
e.g. cat HttpClientRSA.cfg
#host: host name for the http server
host=<your ca host>
#port: port number
port=8080

#secure: true for secure connection, false for nonsecure connection
secure=false

#input: full path for the enrollment request, the content must be in binary format
input=/root/cfu/testCMC/certReq.p10.cmc

#output: full path for the response in binary format
output=/root/cfu/testCMC/certReq.p10.cmc.response

#dbdir: directory for cert8.db, key3.db and secmod.db
#This parameter will be ignored if secure=false
dbdir=/root/cfu/testCMC

#clientmode: true for client authentication, false for no client authentication
#This parameter will be ignored if secure=false
clientmode=false

#password: password for cert8.db
#This parameter will be ignored if secure=false and clientauth=false
password=<replace it with your password>

#tokenname=
#nickname: nickname for client certificate
#This parameter will be ignored if clientmode=false
nickname=PKI Administrator for ca host

#servlet: servlet name
servlet=/ca/ee/ca/profileSubmitCMCFull

* copy the Base64 CMC response result on the screen and pass it into an ASN.1 decoder:
You will find the following (which is the "wrong" OID):
28   12:         SEQUENCE {
  30    8:           OBJECT IDENTIFIER '2 16 840 1 101 3 4 1'
  40    0:           NULL
         :           }
         :         }

============
After reinstalling JSS with the revision with the fix (JSS version > jss-4.2.6-33), go through the above exercise again, and you shall see the following correct OID instead:
  28   13:         SEQUENCE {
  30    9:           OBJECT IDENTIFIER '2 16 840 1 101 3 4 2 1'
  41    0:           NULL
         :           }
         :         }

The next JSS build containing this fix will be available when notified (currently waiting for one other bug to be addressed).
Comment 7 Roshni 2014-11-04 22:14:55 UTC 
I was able to verify the bug on RHEL 7.1 using jss-4.2.6-35.el7. I am not able to reproduce the bug by executing the steps explained in comment 5 on RHEL 7.0 using jss-4.2.6-33.el7.

I was getting the following error when trying to run CMCRequest for the pkcs10 cert request

[root@mgmt8 certs_db]# CMCRequest p10cmc.conf 

cert/key prefix = 
path = ./
CryptoManger initialized
org.mozilla.jss.NoSuchTokenException
	at org.mozilla.jss.CryptoManager.getTokenByName(CryptoManager.java:622)
	at com.netscape.cmstools.CMCRequest.main(CMCRequest.java:1027)

I just wanted to confirm if it is because of the following

> Note1: There is a bug in CMCRequest:
> https://fedorahosted.org/pki/ticket/1158 CMCRequest does not support
> internal token

Is there a different way to reproduce the bug? I tried to use jss-4.2.6-33.el7 on RHEL 7.1 but since tomcatjss has a dependency on jss, it did not go through.
Comment 8 Christina Fu 2014-11-04 22:29:07 UTC 
this is a reply to comment 7:

most likely it is the result of https://fedorahosted.org/pki/ticket/1158.
but you really don't need to do that step on rhel7 or rhel7.1.  It is just the client (tool) side that hits the server to be tested.  I think the fix was checked into the Dogtag so you can run the client there and point to the server if you want.
Comment 9 Roshni 2014-11-04 22:50:04 UTC 
Verified using jss-4.2.6-35.el7 by executing the steps explained in comment 5 and verifying the expected result. Reproduced the bug using jss-4.2.6-33.el7 and compared the differencr in OIDs.
Comment 10 Christina Fu 2014-11-25 18:27:43 UTC 
*** Bug 824624 has been marked as a duplicate of this bug. ***
Comment 12 errata-xmlrpc 2015-03-05 13:22:21 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://rhn.redhat.com/errata/RHBA-2015-0521.html
Note You need to log in before you can comment on or make changes to this bug.