Basil Dolmatov wrote: > > Martin Rex пиÑеÑ: > > > > I'm still quite confused. > > > > All references to GOST signature algorithms of the kind > > [GOST3410] ought to be fixed to say [GOST3410-2001]. > > I think that can de done, despite the fact that there is no other > algorithm coded as GOST 3410, except GOST 34.10-2001.
The problem is that there are IETF documents like rfc-4357 and like the (currently expired) GOST TLS ciphersuites draft that still list GOST R34.10-1994 as a valid algorithm. > > It seems it mixed up the (deprecated) signature Algorithm GOST R34.10-1994 > > and the hash/digest algorith GOST R34.11-1994 that is still being used > > for signatures with GOST R34.10-2001. > > > > It seems that no mixture takes place. Signature standard has number > 34.10, hash standard has number 34.11. > I cannot see how they can be mixed up. I'm sorry for the typo. I meant to say that *I* mixed them up because of their inconsistent naming throughout the GOST-related documents that have been publshed as I-Ds and RFC. That comes mainly from the goof-up in rfc4357 that leaves out the -1994 appendix to the hash algorithm in the section header/contents and tag name. > > > IMHO, rfc4357 should have been completely stripped from GOST R34.10-1994 > > before publication if what you describes really applies to this algorithm. > > I think that is a question to authors of RFC4357 and I think that > corrections should be issued. There is no correction process for RFCs. Preferably the new document about GOST R34.10 signature algorithms should be merged with rfc4357 into rfc4357bis, and this time the GOST R34.10-1994 algorithm should only be mentioned in the Security Considerations as having been completely retired/phased out in 2004. > > > > > Which is not really helpful. Any specification referencing rfc-4357 > > will now have to declare which kind of parameter sets (as defined in > > rfc-4357) should be used/accepted for which purpose and which > > parameter set is the default. > > Yes. And this is done in the draft text. Read it. OK, I'm sorry. For the DNSsec GOST signature I-D, the default/prefered (?) parameter sets are explicitly listed in last paragraph of section 2 of draft-ietf-dnsext-dnssec-gost-06. However, it does _NOT_ say what to do if GOST R34.10-2001 signatures with other parameter sets are encountered. I was confused by the I-D about the GOST R34.10-2001 digital signature algorithm, where the possible parameters sets and their meaning are specified to be pretty unspecified (page 7): GOST R 34.10-2001 does not determine the process of generating parameters needed for digital signature scheme. Possible sets of these parameters are defined for example in [RFC4357]. > > Document - draft-ietf-dnsext-dnssec-gost-06 does not use any "test" > parameters from RFC 4357 and does not reference any of them. The dnssec document references rfc4357 for the definition of the parameter sets, but fails to define what to do if signatures with other parameter sets than the default/preferred one are received. -Martin _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
