<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=windows-1252">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 19/09/2015 15:34, Michael Heide
      wrote:<br>
    </div>
    <blockquote class=" cite"
      id="mid_20150919153416_34bf155b_tbb_phenom"
      cite="mid:20150919153416.34bf155b@tbb-phenom" type="cite">
      <pre wrap="">Am Wed, 16 Sep 2015 08:55:51 +0200 schrieb Michael Heide <a class="moz-txt-link-rfc2396E" href="mailto:michael.heide@student.uni-siegen.de"><michael.heide@student.uni-siegen.de></a>:

</pre>
      <blockquote class=" cite" id="Cite_2324659" type="cite">
        <pre wrap="">My question now is: how to (proper) handle it?
</pre>
      </blockquote>
      <pre wrap="">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.)</pre>
    </blockquote>
    <tt>I am in no position to include this, but here are a few <br>
      thoughts on improving your patch.</tt><tt><br>
    </tt><tt><br>
    </tt><tt>1. The error should not call this "plain", this would lead
      <br>
        to the same misunderstanding I had earlier.  Try something <br>
        like "RSA_R_PKCS1_1_DIGEST_ONLY_VALID" to indicate that this <br>
        is a variant of PKCS#1 v1.x signature formatting (the outer <br>
        part with 00|01|FF....|00 is still there), but without the <br>
        inner DER encoded ASN.1 structure.</tt><tt><br>
    </tt><tt><br>
    </tt><tt>2. Because the hash algorithm OID is not there, something <br>
        needs to check that the hash algorithm is the right one for <br>
        this RSA public key.  This test is really in another layer <br>
        (PKCS#7/CMS), but needs to be stronger in this case due to <br>
        the lack of an embedded hash algorithm identifier inside the<br>
        RSA calculation.</tt><tt><br>
    </tt><tt><br>
    </tt><tt>3. It would be really nice if someone in the know would <br>
        explain under which conditions this alternative signature <br>
        algorithm is used and/or necessary.</tt><tt><br>
    </tt><tt><br>
    </tt><br>
    <pre class="moz-signature" cols="72">Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  <a class="moz-txt-link-freetext" href="http://www.wisemo.com">http://www.wisemo.com</a>
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded </pre>
  </body>
</html>