Am Tue, 15 Sep 2015 23:18:02 +0200 schrieb Jakob Bohm <jb-openssl at wisemo.com>: > Where is *1 ? Sorry, never mind. I screwed it up... > Of cause, this error is really at the PKCS#1 level, even > though the PKCS#7 standard formally repeats that particular > part of PKCS#7 due to ISO/OSI/ITU fun with BIT STRING vs. > OCTET STRING notation. Do you think of Note #1 in chapter 9.4 of rfc 2315? Yes, using the Digest instead of a DigestInfo for the Digest-encryption process seems not covered by rfc 2315. Btw.: for me the problem described in Note #3 seems not as big a problem as it sounds to be. This does indeed work for md5->md2. One can try to match md2 hashes to any signed md5 hash. But not for sha1->md5 or sha256->sha1, because of the differences in length. Maybe that's the reason why it's still in use the way it is done by those timestamp-services and accepted by Windows. That's the thing I wanted to address with the "*1"-thing in my last mail. If there's a 160 bit hash expected, you have to find a 160 bit algorithm which gets accepted by those verifying the signature. If there's only sha1, then you got stuck to sha1, regardless if it's a DigestInfo or a plain Digest. > Yep, it is probably also accepted by Microsoft's generic PKCS#7 > code, since I have in the past checked timestamps from that > server in that way and not noticed the deviation. My question now is: how to (proper) handle it? - continue using a patched and self-compiled openssl? - copy all functionality down to the modified int_rsa_verify() into my own project to use the rest from system-included openssl? - rewrite my source to parse pkcs#7 myself? I'm using a verify_cb() for other things but I didn't find a usable callback for this. Regards Michael
