Subject: RE: ASN.1 as encoding (was: Designing and Allocating a new RR typ e)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 24 Jun 2004 11:27:42 -0700

> > - ASN.1 encoded data only
> > - ASN.1 tagged with a OID for unambigous identification
> >  of the content type
> 
> Hmm, people are discussing possible security problems due to the
> use of XML. What about ASN.1? It seems that writing a parser for
> it is not trivial; just look at some OpenSSL security advisories:
> 
>     o Security: fix vulnerabilities in ASN.1 parsing
>       CAN-2003-0543, CAN-2003-0544                            
> [0.9.7c & 0.9.6k]
>     o Security: fix additional vulnerability in ASN.1 parsing
>       CAN-2003-0545                                           
>          [0.9.7c]

ASN.1 was a great idea and a completely botched design.

Worst of all was the DER encoding lunacy which meant that encoding
a data set is impossible until the whole data set is available.
It is not possible to stream data through an ASN.1 encoder. The
DER encoding in X.509 was a bad, bad bad mistake. It please the
idiots who thought that C18N was relevant to certs, it is not as
is proven by the fact that for years VeriSign certs were not 
DER encoded.

ASN.1 is also much worse than XML in that you cannot understand the
data at any level unless you have access to the schema. 

If ASN.1 had not been botched so badly there would have been no
need for XML.

ASN.1 put back the widespread use of crypto more than any other 
factor. Yes I have written ASN.1 encoders and decoders.