Re: [Trans] RFC6962 BIS Log file encodings.

Erwann Abalea <> Sat, 29 March 2014 23:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CD59F1A07FF for <>; Sat, 29 Mar 2014 16:21:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gqPSvPTvN_GB for <>; Sat, 29 Mar 2014 16:21:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c01::234]) by (Postfix) with ESMTP id DBA921A06B9 for <>; Sat, 29 Mar 2014 16:21:20 -0700 (PDT)
Received: by with SMTP id jz11so6896472veb.25 for <>; Sat, 29 Mar 2014 16:21:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LGHSG0vaZvvHL3yZQFcZtWwy2xYM31phyFCb3O5M4hk=; b=jXmf6EN+ZlHn5q1wq4PD7RjTyOe9UaHO6Gf0W9uYohIW2UFb8l/gPebpOuawxYeOxB RFPw8WGo2N+m4CrVuW6eN9+vRGrSk9gdx1scSckznr6i2H7YAGU8ykQaDKJRYyIeeUXQ l6U/NikXFspu/fdl46fphEDzMmVHFtOPkQgBia/YluC5CwOrxSvjfl7BJNE0zHCvxljz r5myIfx5O8+Ku3oAHobjV1hK++Hn0IveuLe3sOaA0ZHkkhyBCioYuvMSdhUxbnAp7JJp Bla03qe+JvXdbUYDGuwD8wdMTeEfwwMFi6Kb/TZgLEtzTbR5B8ippaE+uWXJAsCzuAqR kK+A==
MIME-Version: 1.0
X-Received: by with SMTP id ry9mr14877936vcb.6.1396135278101; Sat, 29 Mar 2014 16:21:18 -0700 (PDT)
Received: by with HTTP; Sat, 29 Mar 2014 16:21:18 -0700 (PDT)
In-Reply-To: <r422Ps-1075i-50EDDACBA0064390A2CED9708B9D3E07@Williams-MacBook-Pro.local>
References: <> <r422Ps-1075i-50EDDACBA0064390A2CED9708B9D3E07@Williams-MacBook-Pro.local>
Date: Sun, 30 Mar 2014 00:21:18 +0100
Message-ID: <>
From: Erwann Abalea <>
To: Bill Frantz <>
Content-Type: multipart/alternative; boundary="001a1133935c4f766404f5c71351"
Cc: "" <>, Rob Stradling <>, Phillip Hallam-Baker <>, 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: Sat, 29 Mar 2014 23:21:23 -0000

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?

Data structures defined in RFC6962 can be described in ASN.1 as well, and
encoded using PER (that's not common), and it will be binary compatible
with what is proposed. Will it introduce new bugs because of ASN.1?