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

Ben Laurie <benl@google.com> Wed, 09 April 2014 13:13 UTC

Return-Path: <benl@google.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 A64421A02B8 for <trans@ietfa.amsl.com>; Wed, 9 Apr 2014 06:13:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.051
X-Spam-Level:
X-Spam-Status: No, score=-1.051 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_42=0.6, RP_MATCHES_RCVD=-0.272, 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 YZKXDS5hfdCW for <trans@ietfa.amsl.com>; Wed, 9 Apr 2014 06:13:11 -0700 (PDT)
Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A96CB1A028C for <trans@ietf.org>; Wed, 9 Apr 2014 06:13:09 -0700 (PDT)
Received: by mail-vc0-f171.google.com with SMTP id lg15so2106292vcb.30 for <trans@ietf.org>; Wed, 09 Apr 2014 06:13:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ol2/cMDcbtzX2AY07wYah3anWfsPclipdO56r6VP3jU=; b=jd/0YV7oV0x0Yp8HUEhmqIFMKMhAWSF9/xVFqiFh6g09GVvCzG0BzJNjQMVJRuDM8b 7pdAQZw0LW5VyEKDeBxkheSRwJVuRHnT7bLI14WB85W1wwy7JNUICFBExCGxZUz5Isyz XuJUmOsGxRVj7ga01WoLbX2TKw2JIrfPQCMVQnTMkW9/e5Oh3SRYfx1EwA8ohKNG1NCn Bitl4l9LeKT7tAZjqXXp56FFdC9DmPPi+zZmVs9nqZyPh3uRGczs+m+PTtkTcmiMOD7a I/1Hssu+S/gWjqQGlOEl32pb908EIjT2Dsloe/AbgKenaUc5a0Gnzl4CoyVQOHIULjkH os6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ol2/cMDcbtzX2AY07wYah3anWfsPclipdO56r6VP3jU=; b=DQxbE3IIE4qDFHCepaQX/BQ9bfAmBeXdzQgJC0ZF/LVu0SifYe3oaM8OlqPhcsdkO8 gpzbkAi+EYgehC3ajM5t9mXuk3pUZckP1v4wvB/uzu/FFw5ig+NZKhNdr9DVrmOdZhTw NRqzwVGrOL/MmUT86jkhcE+Nju5JlYZZkJ/n6C2TKuh9M8ofK6Q8tefRCCo2PD26r/Yn HmnVEobPmrI5dro/3JOrx+VUGToircrqlz0LTvZnNgh2RwqCb3zKtx5X8zLsz4a3HIKh b8vQBJ2D70lSBQnMfxyLiHke/3V1dwGSr06hXm8Aq2DUPppgFp3psZuIJWYeNgTwmb/J u3RQ==
X-Gm-Message-State: ALoCoQnq78Qgt+hnD7f3HdL9j2zn1naoCqYxkFKfBN3h1veu2hzCU2VpNI/K9aTs6ZYMKvY3miWasAPZws7s5dvyKVP2LsP37GPtaemUp8gNDL4Oxb+gLRLgPKwzufkn+E87OJf8fN9cEGZdkfD76PxUh3a8CAW2XLrtVdLd8nxiGccBoK6ulnTJ/6usBad8x3+FYcCjPkHw
MIME-Version: 1.0
X-Received: by 10.52.249.105 with SMTP id yt9mr450422vdc.34.1397049188968; Wed, 09 Apr 2014 06:13:08 -0700 (PDT)
Received: by 10.52.119.179 with HTTP; Wed, 9 Apr 2014 06:13:08 -0700 (PDT)
In-Reply-To: <CAMm+LwiW-nweMwnVUoLOUoAfWaQKjbws9tw20oma0GM=XahgQg@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> <CADqLbzK=gC7Lv3bkS33i=3x2sM1rTWrT_DejryTcBTTM97uQHQ@mail.gmail.com> <CAMm+LwiW-nweMwnVUoLOUoAfWaQKjbws9tw20oma0GM=XahgQg@mail.gmail.com>
Date: Wed, 09 Apr 2014 14:13:08 +0100
Message-ID: <CABrd9SSEz37r6qqaQci1a9MH0e+uxChf9QhYMAvgyYPn7GkP3w@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/3JApeM87JO_9kIryyYgG6x3iSjM
Cc: "Salz, Rich" <rsalz@akamai.com>, "trans@ietf.org" <trans@ietf.org>, Dmitry Belyavsky <beldmit@gmail.com>, "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: Wed, 09 Apr 2014 13:13:15 -0000

On 9 April 2014 01:49, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> Since TRANS is joined to X.509 at the hip, how about we just shovel
> all the metadata describing the configuration of the notary into the
> certificate that signs the notary log outputs periodically?

I guess if you are a CA everything looks like a certificate.
Currently, logs do not use certificates to manage their own keys. I
guess they could. But I thought you preferred JSON for new stuff?

> I am assuming here that the signing hierarchy for the log has an
> offline key that periodically signs the online key.

Again, currently, no. Seems to me that you can introduce a lot of
complication this way not needed for the only known client use case
(deployment in Chrome). Not against specifying it, to be clear, but
unsure it should live in the same doc. Or hold it up.

> The cert for the
> online key can specify the notary algorithm by OID (its ASN.1 after
> all) and any other parameters that might be useful. Probably want to
> allow for different accumulation strategies in case we ever decide a
> binary tree isn't the only choice. Might have some other options.
> Might want to be able to specify the CPS/CP equivalents for the
> notary, etc.
>
>
>
> On Tue, Apr 8, 2014 at 10:28 AM, Dmitry Belyavsky <beldmit@gmail.com> wrote:
>> 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
>>
>> _______________________________________________
>> Trans mailing list
>> Trans@ietf.org
>> https://www.ietf.org/mailman/listinfo/trans
>>
>
>
>
> --
> Website: http://hallambaker.com/



-- 
Certificate Transparency is hiring! Let me know if you're interested.