IETF Logo Mail Archive

Re: [Trans] Fwd: Certificate Transparency with Russian GOST algorithms

Ben Laurie <benl@google.com> Tue, 01 April 2014 09:35 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 AC4171A0481 for <trans@ietfa.amsl.com>; Tue, 1 Apr 2014 02:35:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.389
X-Spam-Level:
X-Spam-Status: No, score=-1.389 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 4BCZdrwAnOaN for <trans@ietfa.amsl.com>; Tue, 1 Apr 2014 02:35:20 -0700 (PDT)
Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7278D1A0985 for <trans@ietf.org>; Tue, 1 Apr 2014 02:35:20 -0700 (PDT)
Received: by mail-vc0-f170.google.com with SMTP id hu19so9637426vcb.1 for <trans@ietf.org>; Tue, 01 Apr 2014 02:35:16 -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=bdUSs4JwAolgnANA4PAfr889qi9DhyI1710g04OqYpI=; b=Drx12/fAc+81UDpLDrWpuVDviBytg2dzgg4+TTvWE9WUK/SUsciloDwbe8FEQ/jaiM u/wG7xVOaKOBTCkavRFOgObdanuS5B6SgbmjxiXyC0riFdMKJjGI/hc+x+litvHDtpix vUGm4SvELoIZhZP9maWBh42v95WgKtAv7gzVytfzXUvmZPQvzx1D1SwAy/9W/uIOpVKb +95dPdiPl+PB3coq+ld0Kj78Cj/DNn3Bm4/vb4+J/VXDwn+/FQyncuuPy0YmR6sNEH2I Zpx9bV4UXXPaqt+yrZYQLnCPlyMnEAyS4cbC62DcRAKxX2N3uegXjqxXPFVB/vrT4BQY eBGg==
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=bdUSs4JwAolgnANA4PAfr889qi9DhyI1710g04OqYpI=; b=UyIsX2EWEdoBerkRHezZbZ/86316xaLTja6q2ni9UY8Bba2FiPTIW0rL6Xn1jIWJMQ EGQPO+je69+by0bJPzqJNcCcknFQMHMPVP9nJmfvqXhoaCK9IOTw6fMkhXLA5z0WvHuB UaH/QcrSASF5Kip06/KtmDDs/f9MU0UeJuHfqAMYRuAS86aRzD3dz443Zn177mI/gOMX FKM1qVEcjSauu4yaEHDxOEl231OzQ5pfozRBhfuifjHr2W/mb8JzR5IgyKCqY3TMuS8N JfI9l++s0jJtkcBCKq2rvSqCFqPUUmOdCIEYFDsRF+jiQOfoAnizK2uhYz1WxiEymcSg jllQ==
X-Gm-Message-State: ALoCoQlZTYbztvd6MWLgIZxTla7s95Ek/h1f0xMJKH/KSqyizyJQ5qDJ/wAZ6iK4/6XX0yvXTiVf4Z5QTP94zqvQ/fumuyLwWBv1a4ZtA97MIAihtCCPLsYJTzQQ7m5iOxiXoxjTrhQda1WzJ931heGV/zh++4Qjry7Ypn+LL0qg1nwvJVXxfP8MpYFipkhFMykmBWTYU05v
MIME-Version: 1.0
X-Received: by 10.52.12.36 with SMTP id v4mr10322357vdb.20.1396344916800; Tue, 01 Apr 2014 02:35:16 -0700 (PDT)
Received: by 10.52.119.179 with HTTP; Tue, 1 Apr 2014 02:35:16 -0700 (PDT)
In-Reply-To: <CADqLbzLnDvPZ+TAhk_qjKd-6s2DXWJEpnKL-Ldd1nnfa9ci8iw@mail.gmail.com>
References: <CADqLbz+F0tAHSKj32faD+WYzm4WMwbWyMG4eHH=2_pu_g5C8+w@mail.gmail.com> <CABrd9ST2jZ+7bRETAztX8yZnTfOomUHt1gexHXY51_Q+VSrcRA@mail.gmail.com> <CADqLbzLnDvPZ+TAhk_qjKd-6s2DXWJEpnKL-Ldd1nnfa9ci8iw@mail.gmail.com>
Date: Tue, 01 Apr 2014 10:35:16 +0100
Message-ID: <CABrd9STKc48P9B0q608m4jzeXJW926AicS5ZhZqPMTH=o+ad4g@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Dmitry Belyavsky <beldmit@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/xDzwOSjAxxxWJEC9qPWV5Bk1-c0
Cc: "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] Fwd: Certificate Transparency with Russian GOST algorithms
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 09:35:21 -0000

On 1 April 2014 10:25, Dmitry Belyavsky <beldmit@gmail.com> wrote:
> Hello Ben,
>
>
> On Mon, Mar 31, 2014 at 2:51 PM, Ben Laurie <benl@google.com> wrote:
>>
>> On 31 March 2014 09:21, Dmitry Belyavsky <beldmit@gmail.com> wrote:
>> > Dear Ben,
>> >
>> > Sorry for my late response.
>> >
>> > 18.03.2014 18:20, Ben Laurie wrote:
>> >> As I mentioned elsewhere, in our view you change algorithm by starting
>> >> a new log.
>> >
>> > Ok. What about a way to find out the algorithm in use?
>>
>> That is metadata that clients must discover outside the protocol
>> (along with things like MMD, log URL, etc).
>
>
> I think that whether we have to discover the log URL outside the protocol,
> it will be better to specify URL like https://<log server>/ct/meta/ to find
> out the concrete setting f the log server.

That seems like a bad idea, because then log servers could, for
example, vary their promised MMD.

>> >> It seems to me there shouldn't be any difficulty accommodating GOST
>> >> like this - I guess we'd have to add the rule that non-GOST
>> >> certificates MUST NOT use GOST logs. Not sure whether we should
>> >> require the opposite, though (i.e. GOST certificates MUST NOT use
>> >> EC/SHA logs)?
>> >
>> > What is expected to be a right behaviour in case when a certificate has
>> > SCT
>> > from some different log servers, if some of the SCT signatures can't be
>> > verified? If they are to be just ignored, I'm not sure we need such a
>> > limitation.
>>
>> Fair point.
>
>
> So it seems to me that this (or any other reasonable) behaviour should be
> specified somewhere in the section describing TLS client behaviour.

Perhaps you could file a ticket on the issue tracker?

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

v2.14.0 | Report a Bug | By Email