Re: [Trans] RFC6962 BIS Log file encodings.

Bill Frantz <frantz@pwpconsult.com> Sun, 30 March 2014 01:55 UTC

Return-Path: <frantz@pwpconsult.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393921A040E for <trans@ietfa.amsl.com>; Sat, 29 Mar 2014 18:55:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeMaUMUpTw5m for <trans@ietfa.amsl.com>; Sat, 29 Mar 2014 18:55:54 -0700 (PDT)
Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7555F1A0416 for <trans@ietf.org>; Sat, 29 Mar 2014 18:55:54 -0700 (PDT)
Received: from [174.240.13.187] (helo=Williams-MacBook-Pro.local) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <frantz@pwpconsult.com>) id 1WU4yU-0004u6-0e; Sat, 29 Mar 2014 21:55:50 -0400
Date: Sat, 29 Mar 2014 18:55:13 -0700
From: Bill Frantz <frantz@pwpconsult.com>
To: Erwann Abalea <eabalea@gmail.com>
X-Priority: 3
In-Reply-To: <CA+i=0E4byZ8DPgarYxSvKAeq6_nhDyNO5_59_Tw4h6B4Zf1ymw@mail.gmail.com>
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
X-Originating-IP: 174.240.13.187
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/bGxcfLRxhUoI0IBhw5pZp6HN28g
Cc: Phillip Hallam-Baker <hallam@gmail.com>, Rob Stradling <rob.stradling@comodo.com>, trans@ietf.org, Rick Andrews <Rick_Andrews@symantec.com>, Eran Messeri <eranm@google.com>
Subject: Re: [Trans] RFC6962 BIS Log file encodings.
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 30 Mar 2014 01:55:56 -0000

On 3/30/14 at 4:21 PM, eabalea@gmail.com (Erwann Abalea) wrote:

>2014-03-29 23:49 GMT+01:00 Bill Frantz <frantz@pwpconsult.com>om>:
>
>>On 3/28/14 at 11:47 AM, eabalea@gmail.com (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