<html dir="ltr"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style> </head> <body ocsi="0" fpstyle="1"> <div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">Hello all, I have come across what looks like a bug in SCEP responses from the CA when using SHA-256 and SHA-512. 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" When attempting to verify the digest using NSS'SEC_PKCS7VerifySignature() / SEC_PKCS7VerifyDetachedSignature() it fails, and I believe it also fails with similar calls under OpenSSL. There's a mention of the latter on the Dogtag SCEP/SSCEP page under the heading "SSCEP Error". I believe this error is due to this OID discrepancy. I've been looking in the Dogtag source and the JSS Javadocs to see where this OID might be coming from. Everything I've looked at where OIDs for SHA-2 algorithms are concerned have the right bytes, so I've been unable to pinpoint where the OID is coming from. I can provide sample CertRep messages with the odd OIDs in there if desired. A sample signerInfo from a SHA-256 CertRep failure message from dumpasn1 is below: Currently Running: Fedora Core 15 updated to the latest as of 5/17/2012 pki-core (and other rpms) 9.0.19-1 nss-* 3.13.4-2 jss-4.2.6.24 nspr-4.9-2 (I've also seen this behavior with pki-core 9.0.17 and its corresponding packages as well) I did go looking through the mailing lists and bugzilla to see if this issue had been found and didn't see anything. If I did overlook it then please accept my apologies. I'm currently working around the problem by using SHA-1, but I'd really like to be able to use the stronger digest algorithms if possible. If anyone knows how to get that working I'd appreciate it. Thanks, Jamil SAMPLE CertRep Fail signerInfo using SHA-256: 60 623: SET { 64 619: SEQUENCE { 68 1: INTEGER 1 71 72: SEQUENCE { 73 67: SEQUENCE { 75 16: SET { 77 14: SEQUENCE { 79 3: OBJECT IDENTIFIER organizationName (2 5 4 10) : (X.520 DN component) 84 7: PrintableString 'TESTPKI' : } : } 93 15: SET { 95 13: SEQUENCE { 97 3: OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) : (X.520 DN component) 102 6: PrintableString 'pki-ca' : } : } 110 30: SET { 112 28: SEQUENCE { 114 3: OBJECT IDENTIFIER commonName (2 5 4 3) : (X.520 DN component) 119 21: PrintableString 'Certificate Authority' : } : } : } 142 1: INTEGER 1 : } 145 12: SEQUENCE { 147 8: OBJECT IDENTIFIER aes (2 16 840 1 101 3 4 1) : (NIST Algorithm) 157 0: NULL : } 159 250: [0] { 162 17: SEQUENCE { 164 10: OBJECT IDENTIFIER messageType (2 16 840 1 113733 1 9 2) : (Verisign PKCS #7 attribute) 176 3: SET { 178 1: PrintableString '3' : } : } 181 17: SEQUENCE { 183 10: OBJECT IDENTIFIER pkiStatus (2 16 840 1 113733 1 9 3) : (Verisign PKCS #7 attribute) 195 3: SET { 197 1: PrintableString '2' : } : } 200 17: SEQUENCE { 202 10: OBJECT IDENTIFIER failInfo (2 16 840 1 113733 1 9 4) : (Verisign PKCS #7 attribute) 214 3: SET { 216 1: PrintableString '2' : } : } 219 24: SEQUENCE { 221 9: OBJECT IDENTIFIER contentType (1 2 840 113549 1 9 3) : (PKCS #9) 232 11: SET { 234 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) : (PKCS #7) : } : } 245 32: SEQUENCE { 247 10: OBJECT IDENTIFIER senderNonce (2 16 840 1 113733 1 9 5) : (Verisign PKCS #7 attribute) 259 18: SET { 261 16: OCTET STRING : A9 7A AB 92 86 A8 C6 FB A7 AA 59 C8 D8 85 5B 8F : } : } 279 32: SEQUENCE { 281 10: OBJECT IDENTIFIER : recipientNonce (2 16 840 1 113733 1 9 6) : (Verisign PKCS #7 attribute) 293 18: SET { 295 16: OCTET STRING : BD 5F 02 CC D5 5A 25 34 84 00 78 E2 6B 54 D3 7A : } : } 313 47: SEQUENCE { 315 9: OBJECT IDENTIFIER messageDigest (1 2 840 113549 1 9 4) : (PKCS #9) 326 34: SET { 328 32: OCTET STRING : E3 B0 C4 42 98 FC 1C 14 9A FB F4 C8 99 6F B9 24 : 27 AE 41 E4 64 9B 93 4C A4 95 99 1B 78 52 B8 55 : } : } 362 48: SEQUENCE { 364 10: OBJECT IDENTIFIER transID (2 16 840 1 113733 1 9 7) : (Verisign PKCS #7 attribute) 376 34: SET { 378 32: PrintableString '856F90890192FFE9A321C83CB56169AA' : } : } : } 412 13: SEQUENCE { 414 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1) : (PKCS #1) 425 0: NULL : } 427 256: OCTET STRING : 6C 5E EA E3 6E 5B 5D E9 41 72 20 83 33 48 1B 7D : 3F 5F 1F A6 C3 D3 5D D5 F3 D3 57 E7 A7 7C 65 D1 : 25 39 C0 A3 13 E2 63 10 79 28 55 2C 35 51 E0 0F : 63 7B F1 C4 F2 56 E1 63 37 78 01 C1 84 38 44 94 : 46 8F 54 89 E0 FB C1 50 F5 15 9F CA B4 1E A7 68 : C1 DE 96 3C AB 79 33 B8 44 44 F2 A1 0B 03 2A FD : 06 51 5D A1 C6 71 61 50 67 44 C4 94 01 5F 21 1F : EE CF 4B 8D 79 7F 89 45 0D 32 37 AC BE B2 21 A5 : [ Another 128 bytes skipped ] : } : } : } : } : } </div> </body> </html>