IETF Logo Mail Archive

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

Phillip Hallam-Baker <hallam@gmail.com> Tue, 18 March 2014 14:57 UTC

Return-Path: <hallam@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 13F941A017E for <trans@ietfa.amsl.com>; Tue, 18 Mar 2014 07:57:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] 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 XSPpjDVD2W6D for <trans@ietfa.amsl.com>; Tue, 18 Mar 2014 07:57:05 -0700 (PDT)
Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 926E41A036E for <trans@ietf.org>; Tue, 18 Mar 2014 07:57:04 -0700 (PDT)
Received: by mail-lb0-f170.google.com with SMTP id s7so4913665lbd.1 for <trans@ietf.org>; Tue, 18 Mar 2014 07:56:55 -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=2/4F7KC/cgswycoceOAZ73VaTG0uWGVtpvkqzGVYaw0=; b=qB7YXdH4S6XplupZa7ErjHjAXprnLMT9bqdUx0QcRy+IP0Cd2CwKIGet6Pvc/DNh07 RPnWdUvTPDoAHkQzsUM5aCf/NpG5g0/emz0Lm0IQfRI74sUAFLKzqNNhcTN2D1rB2iAU OnF6vHQk6SEiWRakNX5xKzNk2QPKevIzbbxSVSONc3RHot7yaoS9QzGVJcbu3wFyIQ3K umVbeWCF+ZSIJ9FRrQADIE7/rlLPys3YMKFdEzQ1KwKy1/TnXyl2gkkk6Wx6uPIqnZjO XtytwmDRgMcx/81rygcLfMf8WveLz3glxvHyb5DFI/ct7L3W+gLxi1bX3xTt0tXpk51y UGiQ==
MIME-Version: 1.0
X-Received: by 10.152.246.43 with SMTP id xt11mr2136792lac.34.1395154615617; Tue, 18 Mar 2014 07:56:55 -0700 (PDT)
Received: by 10.112.234.229 with HTTP; Tue, 18 Mar 2014 07:56:55 -0700 (PDT)
In-Reply-To: <CABrd9SSOwGC8LKF5viuwoFsjcTMQjra-TJdyWU6g2mVNk_5WOA@mail.gmail.com>
References: <531F530B.4040703@tcinet.ru> <531F57B2.6030505@gmail.com> <CABrd9SSOwGC8LKF5viuwoFsjcTMQjra-TJdyWU6g2mVNk_5WOA@mail.gmail.com>
Date: Tue, 18 Mar 2014 10:56:55 -0400
Message-ID: <CAMm+LwjRkQ6o943U+CZZCT7M9WbtNFGbORaN+ZNNFd=f9HFGrg@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Ben Laurie <benl@google.com>
Content-Type: multipart/alternative; boundary="001a1133a774454dc504f4e2bf27"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/RShINhr6JaJnNTVLcjxNZWAApYU
Cc: Melinda Shore <melinda.shore@gmail.com>, "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, 18 Mar 2014 14:57:11 -0000

On Tue, Mar 18, 2014 at 10:20 AM, Ben Laurie <benl@google.com> wrote:
>
> As I mentioned elsewhere, in our view you change algorithm by starting
> a new log.
>
> The hash/signing algorithms are fixed properties of the log.
>
> 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)?
>
>
Its a little bit more complex than that.

At this point we should note this as a USE-CASE and give it a number. But
there are lots of complexities to consider.


Right now a lot of the inner data structures are specified as a fixed
number of bytes rather than a variable length list. [32] not <32..255>.

That makes it impossible to use the V1 structures to support SHA2-512.

Once you have the possibility for more than one algorithm you need to start
considering algorithm substitution attacks and so the security
considerations section has to be longer at a minimum. You also have to
start putting algorithm identifiers into any place where a substitution
might occur and you have to define what the algorithm identifiers look like.

We could in theory pull the algorithm ids out of the RSA signatures on SCTs
etc. But most crypto libraries are not designed to do that.


-- 
Website: http://hallambaker.com/

v2.28.0 | Report a Bug | By Email | System Status