Re: [Trans] RFC6962 BIS Log file encodings.

[Bill Frantz <[e-mail]>]

On 3/30/14 at 4:21 PM, [e-mail] (Erwann Abalea) wrote:

>2014-03-29 23:49 GMT+01:00 Bill Frantz <[e-mail]>:
>
>>On 3/28/14 at 11:47 AM, [e-mail] (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
[phone]      | it.                          | 16345 
Englewood Ave
www.pwpconsult.com |              - Scott McNealy | Los Gatos, 
CA 95032