[Pki-users] SCEP: Invalid OID in CertRep signerInfo when using SHA-2
Andrew Wnuk
awnuk at redhat.com
Wed May 23 17:59:36 UTC 2012
On 05/22/2012 04:05 PM, Nimeh, Jamil wrote:
> 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
Hi Jamil,
I'll be glad to review this issue. Could open a bugzilla bug?
Thanks,
Andrew
>
> 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 ]
> : }
> : }
> : }
> : }
> : }
>
>
>
>
> _______________________________________________
> Pki-users mailing list
> Pki-users at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-users/attachments/20120523/3b616b9a/attachment.htm>
More information about the Pki-users
mailing list