Steve,
If the decoder possesses meta data, it would be nice for the decoder to
report the location and cause of errors. For example, if the third
extension in a certificate contained the illegal object identifier value
1.99999.3.4, the decoder could report the equivalent of something like:
"Bad object identifier value in first element of SEQUENCE in third element
of SEQUENCE OF in tenth element of SEQUENCE in first element of SEQUENCE."
[I think I got that right.]
If the meta data included the ASN.1 text, the decoder could even describe
the location in ASN.1.
The above description uses 1-based indexing.
Frank
> -----Original Message-----
> From: Dr S N Henson [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 20, 2000 8:15 AM
> To: [EMAIL PROTECTED]
> Subject: Re: rewriting the ASN1
>
>
> SCH wrote:
> >
> > What is the goal of rewriting the ASN1 code?
> > Will Steve try some ASN1 compiler?
> > As to my vision, The c code generated by
> > ASN1 compiler is dirty. Maybe we can write
> > the ASN1 code in openssl with C++.
> >
> > I am to build some PKIX stuff with the current ASN1 routines
> > in Openssl.So If the ASN1 routine is to change, I suggest the
> > progress should keep updated in maillist.
> >
>
> Things are at a very early stage and no code is currently publically
> available, however...
>
> There are quite a few aims for the ASN1 revision.
>
> One goal is to reduce code bloat. As such I want to avoid any option
> that results in lots of code. I'm planning an "intelligent"
> encoder and
> decoder that gets passed a tiny structure describing the ASN1
> structure
> to encode or decode.
>
> It will be possible to hand code the structures with the aid
> of various
> macros. The result should be much more readible than the current mess
> and vastly easier to write.
>
> It should also be possible to post process the output of an SNACC
> 'template' into these structures too.
>
> Another aim (though not initially) is to support stream based
> I/O. As a
> result it should be possible (for example) to process enormous PKCS#7
> structures without ever holding all the content in memory.
>
> 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]
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
