IETF Logo Mail Archive

Re: [Trans] IETF 90 scheduling

Rob Stradling <rob.stradling@comodo.com> Thu, 24 April 2014 15:00 UTC

Return-Path: <rob.stradling@comodo.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 44F061A032E for <trans@ietfa.amsl.com>; Thu, 24 Apr 2014 08:00:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.29
X-Spam-Level:
X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] 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 xAdKWQbkNO1E for <trans@ietfa.amsl.com>; Thu, 24 Apr 2014 08:00:47 -0700 (PDT)
Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFB81A031E for <trans@ietf.org>; Thu, 24 Apr 2014 08:00:46 -0700 (PDT)
Received: (qmail 13632 invoked by uid 1000); 24 Apr 2014 15:00:37 -0000
Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Thu, 24 Apr 2014 16:00:37 +0100
Message-ID: <53592714.4080502@comodo.com>
Date: Thu, 24 Apr 2014 16:00:36 +0100
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "Salz, Rich" <rsalz@akamai.com>, Ben Laurie <benl@google.com>, Jean-Michel Combes <jeanmichel.combes@gmail.com>
References: <53559D3B.1090504@gmail.com> <CAA7e52oXiCW4FfYfz-hT2=QOOm4xXGtxPmVwtC0rbcstQAP9qQ@mail.gmail.com> <CABrd9SRA+TnYXPo0eoNMyMxvVRT8AV39QB2BGb1S1yJ8imx6xg@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E5B1@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E5B1@USMBX1.msg.corp.akamai.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/c3IXK0jFcvkruUd2U69zqcqKCI4
Cc: Melinda Shore <melinda.shore@gmail.com>, "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] IETF 90 scheduling
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: Thu, 24 Apr 2014 15:00:50 -0000

"the log's root"?  Root certificate?

Each log has a raw public/private key, not a root certificate.

Or do you mean something else?

On 24/04/14 15:56, Salz, Rich wrote:
> ØThere's already been a fairly extensive discussion on this, perhaps
> still not resolved. But my position continues to be that the TLS client
> needs to know various things about the log - public key, URL, MMD. I
> don't see the problem in those things being communicated in a data
> structure (e.g. in JSON).
>
> .. and crypto mechanisms being used. At IMHO, this is not resolved.
>
> ØIndeed we will shortly be defining such a structure for Chrome's valid
> logs. Whether this should form part of the RFC is up to the WG.
>
> Yes, at least there.  I think the structure should be embedded in the
> log’s root, for simplicity of deployment evolution, and aiding
> after-the-fact auditing.
>
>                  /r$

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

v2.23.0 | Report a Bug | By Email