DER had a specific purpose, probably application relays. It was
specified for signatures because they are signed and it made some sense
to do this. But a great many players have been unable to create correct
DER encodings. The only possible rule (TM) must be to create DER but
accept BER.
Ron.
> -----Original Message-----
> From: Bodo Moeller [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, June 23, 1999 9:08 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Request verification failure
>
> On Wed, Jun 23, 1999 at 09:57:17AM +0100, Ben Laurie wrote:
> > Holger Reif:
> >> Dr Stephen Henson:
>
> >>> [...] 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.
>
> Yes; an option to accept signatures on non-DER representations makes a
> lot of sense here given that in this case it's earlier versions of the
> same program that generate some non-DER BER where they should generate
> DER. Always checking signatures on the BER-encoded data as presented
> would ridicule the very idea of DER.
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> Development Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
