Re: [Trans] RFC6962 BIS Log file encodings.

Stephen Kent <kent@bbn.com> Mon, 31 March 2014 15:17 UTC

Return-Path: <kent@bbn.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 D0ACB1A0862 for <trans@ietfa.amsl.com>; Mon, 31 Mar 2014 08:17:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.611
X-Spam-Level:
X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 cStGqfwfjQS9 for <trans@ietfa.amsl.com>; Mon, 31 Mar 2014 08:17:00 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 245A41A066B for <trans@ietf.org>; Mon, 31 Mar 2014 08:17:00 -0700 (PDT)
Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49236) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1WUdxQ-000H86-NP for trans@ietf.org; Mon, 31 Mar 2014 11:17:04 -0400
Message-ID: <533986E8.6040201@bbn.com>
Date: Mon, 31 Mar 2014 11:16:56 -0400
From: Stephen Kent <kent@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: trans@ietf.org
References: <r422Ps-1075i-50EDDACBA0064390A2CED9708B9D3E07@Williams-MacBook-Pro.local>
In-Reply-To: <r422Ps-1075i-50EDDACBA0064390A2CED9708B9D3E07@Williams-MacBook-Pro.local>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/a0R5D8KFTnKr7RelzSjT6h_Jlpc
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: Mon, 31 Mar 2014 15:17:02 -0000

Bill,

> 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 fans my say that these bugs have all been fixed, and they may be 
> right if no new ASN.1 interpreters are written.
>
> However, complexity is always a bad thing in a security protocol. Make 
> it only as complex as necessary, and no more complex.
>
> Cheers - Bill
I agree that ASN.1 is complex, and if this were a new protocol, not tied 
to any existing
ASN.1-based data structures, I would not select ASN.1 as a starting 
point. But since we're
talking about data from a TBS cert,since the generators of the data are 
CAs (who should
know how to process ASN.1), and since the consumers of the data are 
browsers who already
process certs, it seems reasonable to stick with ASN.1.

Steve