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

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

(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.

Created attachment 586538 [details]
Second set of CertRep FAIL messages using direct-to-CA SCEP enrollment

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...

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).

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

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}

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.

fixed in jss-4.2.6-35

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