Bug 824624 - SCEP: Invalid OID in CertRep signerInfo when using SHA-2
SCEP: Invalid OID in CertRep signerInfo when using SHA-2
Status: CLOSED DUPLICATE of bug 1040640
Product: Dogtag Certificate System
Classification: Community
Component: SCEP (Show other bugs)
other Linux
unspecified Severity medium
: ---
: ---
Assigned To: Dmitri Pal
Chandrasekar Kannan
Depends On:
Blocks: 530474 1040638
  Show dependency treegraph
Reported: 2012-05-23 16:42 EDT by Jamil Nimeh
Modified: 2015-01-04 18:52 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1040638 (view as bug list)
Last Closed: 2014-11-25 13:27:43 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
PEM encodings for CertRep messages from CA with odd OIDs (9.19 KB, application/zip)
2012-05-23 16:42 EDT, Jamil Nimeh
no flags Details
Second set of CertRep FAIL messages using direct-to-CA SCEP enrollment (3.80 KB, application/zip)
2012-05-24 01:24 EDT, Jamil Nimeh
no flags Details

  None (edit)
Description Jamil Nimeh 2012-05-23 16:42:35 EDT
Created attachment 586462 [details]
PEM encodings for CertRep messages from CA with odd OIDs

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." (it should be ...  For SHA-512 the OID given is "2.16.840."when it should end "..."

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

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

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.
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.".  For SHA-512 the OID in the signerInfo is "2.16.840."

Expected results:
For SHA-256 the OID in the signerInfo should be "2.16.840."
For SHA-512 the OID in the signerInfo should be "2.16.840."

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.
Comment 1 Andrew Wnuk 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 ?
Comment 2 Andrew Wnuk 2012-05-23 19:36:47 EDT
Jamil, Did you try the same test against CA (without RA in the middle)?
Comment 3 Jamil Nimeh 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.
Comment 4 Jamil Nimeh 2012-05-24 01:24:10 EDT
Created attachment 586538 [details]
Second set of CertRep FAIL messages using direct-to-CA SCEP enrollment
Comment 5 Jamil Nimeh 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...
Comment 6 Jamil Nimeh 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).
Comment 7 Nathan Kinder 2012-12-10 15:32:53 EST
Upstream ticket:
Comment 8 David Stutzman 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:

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 9 David Stutzman 2013-12-11 15:07:55 EST
Since the problem with JSS is only the SHA-2 OIDs, a workaround for my case of using the CMC interfaces of the CA is to change the default signing alg of the CA to SHA1withEC and then in the individual ca profiles enforce the desired SHA[256|384|512]withEC algorithm.  I assume dropping the version of JSS my client uses would also work but I did not test that.
Comment 11 Christina Fu 2014-11-25 13:27:43 EST
fixed in jss-4.2.6-35

*** This bug has been marked as a duplicate of bug 1040640 ***

Note You need to log in before you can comment on or make changes to this bug.