Bodo Moeller wrote:
>
> >>> As you asked I send you two of those
> >>> requests that pass the verification test of SSLeay 0.8.1 but not of
> >>> OpenSSL 0.9.2b and higher (I didn't test the versions in between).
>
> >> I tested DrorReq.pem with SSLeay 0.8.1b (which, I think, is like 0.8.1
> >> except for a change related to the Bleichenbacher attack on PKCS #1,
> >> which did not have any effect on any actual computations), and
> >> verification failed also with that version. Both with 0.8.1b and
> >> 0.9.2b, the hash can be obtained from the RSA signature and has
> >> correct length etc., but differs from the one computed for
> >> verification.
>
> I must have made some silly mistake with 0.8.1b -- OpenSSL 0.9.2b is
> the first version where those verifications fail. The reason is a bug
> in all earlier versions; the certification requests indeed are
> incorrect.
>
> Explanation:
>
> Certification requests contain attributes, namely
> Attributes ::= SET OF Attribute.
> In your example, there is a challengePassword attribute and an
> unstructuredName attribute, because those are in the req_attributes
> section of the configuration file. Distinguished Encoding Rules
> mandate that the elements of a set be written in lexicographic order,
> but SSLeay and OpenSSL up to version 0.9.2b do not always do that.
> Here's the critical part from DrorReq.pem in the order in which it
> occurs in the file (note that each Attribute is a SEQUENCE):
>
> <30 17 06 09 2A 86 48 86 F7 0D 01 09 07 31 0A 13 08 49 67 6E 6F 72 65 64>
> ^^
> 303 30 23: SEQUENCE {
> <06 09 2A 86 48 86 F7 0D 01 09 07>
> 305 06 9: OBJECT IDENTIFIER
> : challengePassword (1 2 840 113549 1 9 7)
> [...]
> <30 17 06 09 2A 86 48 86 F7 0D 01 09 02 31 0A 16 08 49 67 6E 6F 72 65 64>
> ^^
> 328 30 23: SEQUENCE {
> <06 09 2A 86 48 86 F7 0D 01 09 02>
> 330 06 9: OBJECT IDENTIFIER unstructuredName (1 2 840 113549 1 9 2)
>
> This is not in lexicographic order, as 02 < 07. When the certification
> request is read by OpenSSL, it is converted into an internal format,
> and then the DER representation is computed from this internal format
> -- verification uses this re-computed value. If you look closely,
> you'll see that the output of "openssl req -in DrorReq.pem" differs
> from the original file because the SET OF encoding is done correctly.
Hmmm. A similar could happen with the PKCS#7 and certificate routines:
some PKCS#7 implementations don't correctly sort authenticated
attributes and some certificates are filled with horrible stuff like
indefinite length encoding. The usual workaround is to verify the
signature on the original data or order rather than a re-encoded version
of it: this is done in a few places already.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
