Re: [Trans] RFC6962 BIS Log file encodings.

Bill Frantz <> Sun, 30 March 2014 01:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 393921A040E for <>; Sat, 29 Mar 2014 18:55:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OeMaUMUpTw5m for <>; Sat, 29 Mar 2014 18:55:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7555F1A0416 for <>; Sat, 29 Mar 2014 18:55:54 -0700 (PDT)
Received: from [] (helo=Williams-MacBook-Pro.local) by with esmtpa (Exim 4.67) (envelope-from <>) id 1WU4yU-0004u6-0e; Sat, 29 Mar 2014 21:55:50 -0400
Date: Sat, 29 Mar 2014 18:55:13 -0700
From: Bill Frantz <>
To: Erwann Abalea <>
X-Priority: 3
In-Reply-To: <>
Message-ID: <r422Ps-1075i-6E5DE00EC7A24146A04D83472CAECFD9@Williams-MacBook-Pro.local>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.3.1 (422)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79ebaf39519cb3038010bd134b84cc41bb350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
Cc: Phillip Hallam-Baker <>, Rob Stradling <>,, Rick Andrews <>, Eran Messeri <>
Subject: Re: [Trans] RFC6962 BIS Log file encodings.
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 30 Mar 2014 01:55:56 -0000

On 3/30/14 at 4:21 PM, (Erwann Abalea) wrote:

>2014-03-29 23:49 GMT+01:00 Bill Frantz <>:
>>On 3/28/14 at 11:47 AM, (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
>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 |              - Scott McNealy | Los Gatos, 
CA 95032