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

From: Dmitry Belyavsky <[email-masked]>
Date: Mon, 31 Mar 2014 12:21:36 +0400

Dear Ben,

Sorry for my late response.

18.03.2014 18:20, Ben Laurie wrote:

On 11 March 2014 18:36, Melinda Shore
<[email-masked]><[email-masked]>wrote:

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

Melinda

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

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
limitation.

-- 
SY, Dmitry Belyavsky

---

From: Ben Laurie <[email-masked]>
Date: Mon, 31 Mar 2014 11:51:43 +0100

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

> verified? If they are to be just ignored, I'm not sure we need such a

Fair point.