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

From: Melinda Shore <[email-masked]>
Date: Tue, 11 Mar 2014 10:36:34 -0800

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

-- 
SY, Dmitry Belyavsky

---

From: Ben Laurie <[email-masked]>
Date: Tue, 18 Mar 2014 14:20:49 +0000

> requirements of cryptographic algorithms agility.

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

---

From: Rob Stradling <[email-masked]>
Date: Tue, 18 Mar 2014 14:46:47 +0000

On 18/03/14 14:20, Ben Laurie wrote:
<snip>
> like this

The GOST algorithms aren't currently in the TLS SignatureAlgorithm and 
HashAlgorithm registries [1].  Since RFC6962 can only reference 
algorithms that are defined in these registries, this looks like a problem.

This I-D [2] (see section 6) tentatively requested adding the GOST 
algorithms to these registries, but it expired long ago and AFAICT never 
progressed to RFC status.

[1] 
http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-16

[2] http://tools.ietf.org/html/draft-chudov-cryptopro-cptls-04

> - I guess we'd have to add the rule that non-GOST

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 18 Mar 2014 10:56:55 -0400

> require the opposite, though (i.e. GOST certificates MUST NOT use
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/