Am Wed, 16 Sep 2015 08:55:51 +0200 schrieb Michael Heide <michael.heide at student.uni-siegen.de>: > My question now is: how to (proper) handle it? Maybe a more sensible way to handle those signatures with OpenSSL is to still not allow such things but instead return an error indicating success if it /would/ be allowed to do it this way? The application then can check for this specific error and translate it into success. (meaning: this specific error is set if OpenSSL successfully compared both hashes and is - as such - not really a fatal error.) This way OpenSSLs default behaviour won't change, it's still an error to not encapsulate the encryptedDigest in an asn1 structure. But the application programmer is able to handle it. see attachment. (Maybe a callback-function at the place where the error gets generated would be a better option. But I think that would be a more extensive change in OpenSSL.) Regards Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: non-enveloped-hash.patch Type: text/x-patch Size: 1714 bytes Desc: not available URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150919/18d737b9/attachment.bin>
