IETF Logo Mail Archive

Re: [Trans] RFC6962 BIS Log file encodings.

Gervase Markham <gerv@mozilla.org> Tue, 01 April 2014 08:30 UTC

Return-Path: <gerv@mozilla.org>
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 563641A095B for <trans@ietfa.amsl.com>; Tue, 1 Apr 2014 01:30:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.278
X-Spam-Level:
X-Spam-Status: No, score=-3.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3] 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 lojl7X4JKFPG for <trans@ietfa.amsl.com>; Tue, 1 Apr 2014 01:30:36 -0700 (PDT)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id E5BAB1A08E8 for <trans@ietf.org>; Tue, 1 Apr 2014 01:30:36 -0700 (PDT)
Received: from [192.168.0.100] (93.243.187.81.in-addr.arpa [81.187.243.93]) (Authenticated sender: gerv@mozilla.org) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 3640EF212C; Tue, 1 Apr 2014 01:30:33 -0700 (PDT)
Message-ID: <533A7928.4050502@mozilla.org>
Date: Tue, 01 Apr 2014 10:30:32 +0200
From: Gervase Markham <gerv@mozilla.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:30.0) Gecko/20100101 Thunderbird/30.0a2
MIME-Version: 1.0
To: Stephen Kent <kent@bbn.com>, trans@ietf.org
References: <r422Ps-1075i-50EDDACBA0064390A2CED9708B9D3E07@Williams-MacBook-Pro.local> <533986E8.6040201@bbn.com>
In-Reply-To: <533986E8.6040201@bbn.com>
X-Enigmail-Version: 1.7a1pre
OpenPGP: id=9DF43DBB
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/4foF7kt5Q4JjSpZV_O06KBzlf0o
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 08:30:38 -0000

On 31/03/14 17:16, Stephen Kent wrote:
> 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.

AIUI, when a browser receives a cert, it will need to reconstruct the
pre-cert in order to check that the SCT (which is a signature over the
pre-cert) is valid. If that is the case, is it not true that browsers
will need to develop some way of _encoding_ ASN.1 which they did not
need to have before?

(I may well be wrong about this; please correct me if so.)

Gerv

v2.23.0 | Report a Bug | By Email