Dr Stephen Henson wrote:
>
> 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.
Is it switchable?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
