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

Dmitry Belyavsky <> Mon, 31 March 2014 08:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 547EA1A0980 for <>; Mon, 31 Mar 2014 01:21:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MgXBrDMoM6hK for <>; Mon, 31 Mar 2014 01:21:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c01::229]) by (Postfix) with ESMTP id 9F4BC1A077D for <>; Mon, 31 Mar 2014 01:21:39 -0700 (PDT)
Received: by with SMTP id v1so7321896yhn.28 for <>; Mon, 31 Mar 2014 01:21:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=mssIbD7OmDfQydQDqwNyneSjUUa8I3ZVTTwO+iNZ6Es=; b=jfWpAEaLX9WgWKs/E43+cq9P5x1hAvvLOUUc84/rFuTiSdUmiUivQPvOoKlNBaYmH1 qlVfTpiECM5fqqIXosu22HLyCezD8rjlCtR8xBLO8oVmcYuco+4cU5i6+IQLrboqEC0h v5vouwdLs1BKmhCshQhm37LlddLd2k8iMrJYL8bxrUyR538YFvctaW4J7Xrc7RzVu05q +mPjmpz+lrgi8spaQ9xc8VYf+6URyQO9n/X94w02dNl09/wfGHK7p/CE7Wgwb5vuwYph Lkh9Gv2a3cFRTWZdSipGchUwKlWKtd2he1hhZQxQ5P1oxz0oNBD9pZ66M6G2kxnUbsv1 52dw==
MIME-Version: 1.0
X-Received: by with SMTP id e46mr33435671yhh.24.1396254096498; Mon, 31 Mar 2014 01:21:36 -0700 (PDT)
Received: by with HTTP; Mon, 31 Mar 2014 01:21:36 -0700 (PDT)
Date: Mon, 31 Mar 2014 12:21:36 +0400
Message-ID: <>
From: Dmitry Belyavsky <>
Content-Type: multipart/alternative; boundary="20cf303b41cd70601d04f5e2bdfd"
Subject: Re: [Trans] Fwd: Certificate Transparency with Russian GOST algorithms
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 31 Mar 2014 08:21:42 -0000

Dear Ben,

Sorry for my late response.

18.03.2014 18:20, Ben Laurie wrote:

On 11 March 2014 18:36, Melinda Shore

For some reason Dmitry's mail is not arriving at the
IETF server, so I thought I would forward it myself.


-------- Original Message --------
Subject: Certificate Transparency with Russian GOST algorithms
Date: Tue, 11 Mar 2014 22:16:47 +0400
From: Dmitry Belyavsky <> <>

Hi all!

Here are some thoughts about using CT in Russia with Russian
cryptographic algorithms (GOST). They were discussed with Ben Laurie
during the IETF meeting in London. I am not sure which mailing list is
the right place to post to, so I post it to the WG mailing list.

Laws and practice in Russia requires using of the GOST hash and digital
signature in X.509 certificates for government services. These
certificates are signed by Russians CAs which are not in lists of
trusted CAs in major browsers. It is not a problem to create an
installation of log server in Russia containing the list of Russian CAs.
But Russia-based service should use the GOST hash algorithm in the
Merkle tree and GOST signature algorithm for signing SCT. It seems to be
not a problem because if GOST-based certificates are submitted to
GOST-based log, browsers not understanding the GOST algorithms will not
have to verify GOST-based SCTs. But also it means that the hashing
algorithm of Merkle tree should become the config-time parameter of the
log instance instead of being hardcoded. Also it should be possible to
find out which algorithm is used in this or that log instance and it
should be strictly prohibited to change this algorithm after start of
the log instance. It seems to be a good idea anyway because of the
requirements of cryptographic algorithms agility.

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?

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)?

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

SY, Dmitry Belyavsky