Bug 1040640

+++ 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}