Re: [Trans] RFC6962 BIS Log file encodings.

Bill Frantz <frantz@pwpconsult.com> Tue, 01 April 2014 06:00 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 E04ED1A6FD6 for <trans@ietfa.amsl.com>; Mon, 31 Mar 2014 23:00:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 a2i4S_LuhtPX for <trans@ietfa.amsl.com>; Mon, 31 Mar 2014 23:00:23 -0700 (PDT)
Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id C2EF01A096C for <trans@ietf.org>; Mon, 31 Mar 2014 23:00:23 -0700 (PDT)
Received: from [173.75.83.234] (helo=Williams-MacBook-Pro.local) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <frantz@pwpconsult.com>) id 1WUrkB-0004mE-Ho for trans@ietf.org; Tue, 01 Apr 2014 02:00:19 -0400
Date: Mon, 31 Mar 2014 22:59:49 -0700
From: Bill Frantz <frantz@pwpconsult.com>
To: trans@ietf.org
X-Priority: 3
In-Reply-To: <533986E8.6040201@bbn.com>
Message-ID: <r422Ps-1075i-F609ABACDF8640D7BBEA493172D4438F@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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec792cff6a674c926c194ecf43c409525434350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 173.75.83.234
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/X-uVJ70Zz8vKamuu78uYiJ_y1bQ
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: Tue, 01 Apr 2014 06:00:25 -0000

On 3/31/14 at 8:16 AM, kent@bbn.com (Stephen Kent) wrote:

>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.

On 3/31/14 at 8:19 AM, rsalz@akamai.com (Salz, Rich) wrote:

>Adding another encoding makes things more complex.  Therefore, the simplest thing to do is use ASN.1
>
>It's like when you're editing someone else's source code: the 
>best thing to do is preserve the existing style.

On 3/31/14 at 8:28 AM, benl@google.com (Ben Laurie) wrote:

>As I just mention, its not actually another encoding - the data
>structure can also (ideally should also) be sent as a TLS extension,
>in which case ASN.1 is not the simplest thing to do.

Stephen, Rich and Ben make good points. It's too bad the 
conclusions differ.

Cheers - Bill

--------------------------------------------------------------
Bill Frantz        | There are now so many exceptions to the
408-356-8506       | Fourth Amendment that it operates only by
www.pwpconsult.com | accident.  -  William Hugh Murray