[openssl-users] PKCS7->signerInfo->encryptedDigest not type X509_SIG

[Michael Heide]

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