OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Fwd: [e-lang] Protocol implementation errors

[ Lists Home | Date Index | Thread Index ]

On Friday 03 October 2003 15:49, Miles Sabin wrote:
> Tyler Close wrote,
> > On Friday 03 October 2003 15:06, Rich Salz wrote:
> > > In every case so far, it's been untested code paths.  As others
> > > have said, that's not ASN1/[BDPX]ER's fault.
> >
> > What if the design of ASN1/[BDPX]ER yields many more code paths
> > than other designs? Is that a design flaw?
> Arguably it might be if that were the case. Is it tho'? Can you show
> that the design of ASN1/[BDPX]ER is such that all plausible
> implementations must have "many" more code paths than a plausible
> implementation of a validating XML parser (or XML+WXS, or XML+RNG, or

That's not my job. I'm not the one proposing a change in
implementation tools, the ASN.1 advocates are. We have data points
to suggest that ASN.1 implementations may be difficult to test. I
think this issue must be addressed by the ASN.1 advocates. They
have to show it's no worse than the existing technology.

> I'd be happy to be corrected, but _intutively_ I find
> that somewhat implausible.

I think the point I made in response to Simon St. Laurent is
relevant here:

On Friday 03 October 2003 13:15, Tyler Close wrote:
> On Friday 03 October 2003 13:10, Simon St.Laurent wrote:
> > In my explorations, ASN.1 toolkits felts more to me like data-binding
> > kits than XML parsers.  There doesn't seem to be much notion of anything
> > like an "ASN.1 infoset", a set of containers and properties you can
> > explore without necessarily knowing the bindings.  ASN.1 feels
> > effectively schema-driven, designed from the outset to be optimized for
> > a world where processes are tightly bound.  There aren't general ASN.1
> > "parsers" in the same sense that there are XML parsers, or at least
> > there weren't last time I looked.
> This lack of layering might be a contributing factor to the
> persistence of bugs in ASN.1.
> The merging of the "infoset" and the "schema" can be seen as
> merging of the lexer and the parser. By complicating the lexer,
> ASN.1 has made itself more vulnerable to bugs commonly associated
> with a lexer, such as buffer overflow.

Rich Saltz also made this point, though less directly:

On Friday 03 October 2003 14:56, Rich Salz wrote:
> In my experience, fixing "too long" errors for XML parsers has to happen
> in only one place. Fixing them for ASN.1/[BDP]ER parsers requires
> fixing it every time you nest a structure or list

This is the implementation and testing impact of merging the lexer
and parser.

On Friday 03 October 2003 15:49, Miles Sabin wrote:
> Personally, based on a mild acquaintance with with the OpenSSL source, I
> think the bulk of the responsibility for the recent and not so recent
> OpenSSL flaws lies neither with the design of ASN1/[BDPX]ER, nor with
> sloppy coders, but with a large and by now somewhat crufty legacy
> codebase.

Everybody gets crufty eventually. The design must cope with that.


The union of REST and capability-based security:


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS