IETF Logo Mail Archive

Re: [Trans] [saag] draft-iab-crypto-alg-agility-00

Dmitry Belyavsky <beldmit@gmail.com> Tue, 08 April 2014 14:28 UTC

Return-Path: <beldmit@gmail.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 D64AE1A040A; Tue, 8 Apr 2014 07:28:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_42=0.6, 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 h07902V4Lblo; Tue, 8 Apr 2014 07:28:52 -0700 (PDT)
Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) by ietfa.amsl.com (Postfix) with ESMTP id CE1FC1A0415; Tue, 8 Apr 2014 07:28:51 -0700 (PDT)
Received: by mail-yk0-f171.google.com with SMTP id q9so864053ykb.16 for <multiple recipients>; Tue, 08 Apr 2014 07:28:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UgBaXS/icUxVU2t8r9yTc2fYXjbd0fNiFgvBJCVhkYc=; b=xfQNQhgYKQqj0ZLB6CLKFpf+wGosiRMd1c/vfzQ8YAZncCz9xk1q+Ui6wFoFxjVctY vazAzUAB6iCTY7HTwPEAhDROwRMi9E8FCjAFkta/30Buzre2FSRzVn7W+72dSDFWWVza BshhmRA6G2JwuwQ5yBcQ9bpEmmQHOH25Fes4WCWSaCU0uM9lMIyyN4EjU12Iy96OofPb Zg7I4A9pW7RuQ7F6tAW2BEPyNQr0m4a5IeUdNRP7grSUJ5tahDk+W/6Ihr/D2lDFBlv4 npwHPNFGs2LP/REEA7ndX4lN6Ggbhm0XU4AcQRTMdrGqHU5agIxLBQRnbDg6YND7L2X2 uegg==
MIME-Version: 1.0
X-Received: by 10.236.4.225 with SMTP id 61mr3442558yhj.108.1396967331519; Tue, 08 Apr 2014 07:28:51 -0700 (PDT)
Received: by 10.170.220.193 with HTTP; Tue, 8 Apr 2014 07:28:51 -0700 (PDT)
In-Reply-To: <CABrd9SRjvexZb5-qo_PsQNLu9BSxbH1zUOCYtomzutXF68j2ZA@mail.gmail.com>
References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <CAG5KPzzqSQ++YpQcnYesecL0GQ0+J0ieMXBrNk6txMAC58xEQQ@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <CAG5KPzxihe+k0x0njC+BANacmrrQyfU5RAY_EYcMYW2rx8DZfw@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> <CAG5KPzzzmJhcPfs0cJuS3f8Lu_Rua9dj0XWaOZ0RQ0Mwyd+egw@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18663@USMBX1.msg.corp.akamai.com> <CABrd9SQaGTFzRaaxs7HNJ7uD_Bb=qPtCtTTsu-ZFYh+QAduzsg@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188A7@USMBX1.msg.corp.akamai.com> <CABrd9SQpaDn=FWCtpRxOprt1nus_Fbg6a9dpbDrdjoWi=H8NBg@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188BB@USMBX1.msg.corp.akamai.com> <CABrd9SRjvexZb5-qo_PsQNLu9BSxbH1zUOCYtomzutXF68j2ZA@mail.gmail.com>
Date: Tue, 08 Apr 2014 18:28:51 +0400
Message-ID: <CADqLbzK=gC7Lv3bkS33i=3x2sM1rTWrT_DejryTcBTTM97uQHQ@mail.gmail.com>
From: Dmitry Belyavsky <beldmit@gmail.com>
To: Ben Laurie <benl@google.com>
Content-Type: multipart/alternative; boundary="089e013cc12a8ee2ce04f688cde1"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/XKIInnxjoRPuuLaH7wP9OenmifE
Cc: "Salz, Rich" <rsalz@akamai.com>, "trans@ietf.org" <trans@ietf.org>, "saag@ietf.org" <saag@ietf.org>
Subject: Re: [Trans] [saag] draft-iab-crypto-alg-agility-00
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, 08 Apr 2014 14:28:53 -0000

Hello Ben,


On Tue, Apr 8, 2014 at 6:21 PM, Ben Laurie <benl@google.com> wrote:

> On 8 April 2014 15:18, Salz, Rich <rsalz@akamai.com> wrote:
> >> > I do not understand why metadata is more secure then the data itself.
> >
> >> It is created by a different authority.
> >
> > ?  Is this in the part of the RFC that is still TBD?
>
> The RFC describes how logs work and how clients work. It does not
> describe how clients decide what logs they are prepared to accept. I
> am not sure it should.
>
> But whoever does also decides whether the algorithms in use by the
> logs are acceptable and tells the client what those algorithms are
> (along with other things, like the log's key, base URL and MMD).
>
> I think that the client should be able to find out the algorithm used by
log because it cant'be changed during the log lifetime. And if the RFC
specifies the URIs for certificate submit, it seems to me that it's
reasonable to specify the URI for finding out the algorithm. But I prefer
to leave out of band of the protocol only the data that can't be passed
using it.

Thank you!

-- 
SY, Dmitry Belyavsky

v2.23.0 | Report a Bug | By Email