Dr Stephen Henson <[EMAIL PROTECTED]> wrote:
>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.
For any sort of signature computation, you have to keep the original around,
you can never rely on being able to reconstruct it yourself because then
you'd have to emulate the encoding bugs of two dozen different
implementations, and keep track of which bugs are present at which point in
the encoding. It gets worse though, you have to keep not only the original
signed quantity, but also any parts of it which may be required later for
use as keys which refer to other objects. For example if your implementation
reads a DN into an internal form and you create a CRL using this, you have
to keep a copy of the original DN and copy that (as a blob) into the CRL
rather than writing the encoding of your internal copy, because there are
implementations which will perform a straight byte-by-byte comparison of the
encoded DN's, and if the two encoded forms differ, will fail to recognise
them as being the same thing.
It's pretty messy, eventually you wind up having to cache the encoded form
of a lot of certificate fields. Currently I cache the cert as a whole, the
subject and issuer DN's, and key identifiers in extensions, this has worked
with all the certs and implementations I've found to date. The easiest way
to handle this is to cache the whole encoded object (signed attributes/cert/
whatever) and keep a block of pointer+length pairs which reference any fields
you need to use inside the object.
Peter.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
