Dear Ben, Sorry for my late response.
18.03.2014 18:20, Ben Laurie wrote: On 11 March 2014 18:36, Melinda Shore <[email protected]><[email protected]>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 protected]> <[email protected]> To: [email protected] CC: [email protected] 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
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
