ietf-mxcomp
[Top] [All Lists]

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

2004-06-24 11:27:46


- 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.


<Prev in Thread] Current Thread [Next in Thread>
  • RE: ASN.1 as encoding (was: Designing and Allocating a new RR typ e), Hallam-Baker, Phillip <=