Ben Laurie wrote:
>
> Dr Stephen Henson wrote:
> >
> > Ben Laurie wrote:
> > >
> > > Holger Reif wrote:
> > > >
> > > > Dr Stephen Henson schrieb:
> > > > >
> > > > > 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.
> > > >
> > > > This discussion has a long history. There has been a
> > > > discussion with eric on this behalf long ago. But
> > > > AFAIR Eric was not convinced to make signature
> > > > verification on the original data. Perhaps he
> > > > believed that eventually the correct solution (tm)
> > > > only will survive ;-)
> > >
> > > I agree with Eric, though an ability to enable buggy behaviour is also
> > > acceptable.
> > >
> >
> > Well ideally you shouldn't have to verify signatures on the original
> > data.
> >
> > In practice if you completely re-encode certificates a large proportion
> > of them will fail a signature: including those made with previous
> > version of SSLeay itself! So many in fact that it would render such
> > "correct" software useless.
> >
> > The only reason this doesn't happpen at present and hasn't in the past
> > is because not all of a certificate is decoded: some things like
> > certificate extensions are kept as a "blob". So it could be argued that
> > it partially verifies signatures on the original data already.
> >
> > To give one example...
> >
> > The BIT STRING should not have any trailing zeros in its encoding unless
> > it is used to contain another structure (e.g. legacy cases like public
> > keys and digital signatures in certificates). Lots of certificates don't
> > follow this rule with things like netscape-certificate-type and
> > keyUsage. SSLeay didn't follow this either: OpenSSL does.
>
> I'm not arguing with that, but I think the behaviour should not be the
> default.
>
Well to some extent it is the default already: certain parts of ASN1
structures are encoded as "blobs". Other structures take some notice of
the original encoding, like BIT Strings: they don't re-encode using DER
rules, they re-encode using the original content octets (which may not
be DER encoded). It just happens that these things are often encoded
incorrectly and several problems are avoided that way.
Anyway there are various possible solutions to the original problem, all
a bit messy.
One is to note the original encoding and then compare it with what we
think it should be. If they match then fair enough: we can discard the
original, if they don't match then the original encoding is retained for
signature verification.
There are a few complications with this...
Any other ideas anyone?
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]
