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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf