On 3/30/14 at 4:21 PM, [email protected] (Erwann Abalea) wrote:
2014-03-29 23:49 GMT+01:00 Bill Frantz <[email protected]>:
On 3/28/14 at 11:47 AM, [email protected] (Erwann Abalea) wrote:
I don't see the problem with ASN.1.
IMHO, the problem with ASN.1 is that it is too complex. There exists a
history of attacks on computer security by sending malformed ASN.1
irritating bugs in ASN.1 encoders. In addition, the ability to specify
"infinite" length data has caused buffer overruns.
ASN.1 isn't a stream of bytes. It's only a language used to describe a
structure, and it needs some encoding rule to serialize data transmitted on
the wire. Use another encoding rule, and you'll have a different bit/byte
representation.
The mentioned bugs (infinite length) are to be found on some BER/DER
encoders, and similar ones can be found on XML parsers, MS Word files
loaders, and many others.
If a certificate is encoded using XER and an XML parser is hit by a bug,
can the fault be attributed to ASN.1, the language used to describe a
certificate? If the same format is described with another language while
keeping the same binary representation, will it make the bug disappear?
Yes, part of the problem is at the description level. The
description language is too general. If I describe a data
structure as: a 16 bit length field followed by the bytes of the
data, then I can't have any data longer than 64K bytes. It is
easy to allocate a buffer that is long enough.
The disadvantage of this form of description is that we may need
to expand to data longer than 64K, needing a new description.
Cheers - Bill
-----------------------------------------------------------------------
Bill Frantz | Privacy is dead, get over | Periwinkle
(408)356-8506 | it. | 16345
Englewood Ave
www.pwpconsult.com | - Scott McNealy | Los Gatos,
CA 95032
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
