ietf
[Top] [All Lists]

Re: draft-ietf-dnsext-dnssec-gost

2010-02-16 10:14:56
Perhaps it would help elucidate matters if we knew the precise criteria

In particular, is the requirement to support Gost or is it that all the algs used be approved

If the second case 1) what would be the root zone criteria and 2) would these regulation issues disappear if the root zone were differently managed?


Sent from my iPhone

On Feb 15, 2010, at 10:09 AM, "Rex, Martin" 
<martin(_dot_)rex(_at_)sap(_dot_)com> wrote:



-----Original Message-----
   This document:


http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost34102001-08

   says

   section 1.1:

      4. GOST R 34.10-2001 replaces GOST R 34.10-94.

   section 1,2:

      GOST R 34.10-2001 is developed to replace GOST R 34.10-94.


Both statement are right.

:-)

Both statements are completely useless.

AES is a replacement/successor to DES.
SHA-2 is a replacement to SHA-1.  So what?

Getting rfc-4357 published without the slightest indication
that the acceptibility of GOST R34.10-1994 had already expired
2 years before is a serious problem in that document.

What really confuses me is that software that there are
GOST toolkits shipped even today that support GOST R34.10-1994.

OpenSSL also contains an implementation of GOST R34.10-1994
and the GOST TLS ciphersuites draft also contains a ciphersuite
with a GOST R34.10-1994 signaturer algorithm.


In effect, whether and how much GOST R34.10-1994 is deprecated
remains a complete mystery.




2. GOST R 34.10-2001 was accepted and activated by the Act 380-st of
  12.09.2001 issued by the Russian federal committee for standards.

  ...

4. GOST R 34.10-2001 replaces GOST R 34.10-94.

So, GOST -1994 for digital signature _is_ deprecated and
replaced from 12.09.2001.

The transition period is not stated explicitly because it is
obvious from standard procedure of certification in Russia.


I would like to remind you that we are the IETF here, and
that implementations of DNS-SEC must remain possible without
an official certification in Russia.

DNS-SEC would not make much sense if it could not be used
by implementations that are _not_ certified in Russia.



   That information OUGHT to have been added to rfc-4357
and it ought to be
   added to draft-dolmatov-cryptocom-gost34102001-08.

Why?
Now is 2010, and all implementations of -1994 standard have
been completely phased out more than 5 years ago.


There seems to be a disagreement between this statement and
reality.

The GOST crypto toolkit shipped by the Company CryptoPro
(author behind rfc-4357 and draft-chudov-cryptopro-cptls-04)
still implements GOST R34.10-1994, and both documents
list GOST R34.10-1994 in a fashion that does _NOT_
suggest that this algorithm may no longer be used.

The GOST implementation in OpenSSL, provided by a different
russian company, also implements/provides GOST R34.10-1994.



This statement was inserted following the advice of Russ Housley.

The main reason for that was that this text is a
_translation_ of the text of official Russian state standard.
At the moment of its creation this text was thoroughly
checked with authors of original standard for consistency.
Any editorial changes/corrections could diverge the
translation from the original, which is undesirable.

I agreed with this Russ's reasoning.


I agree to the intent.

The words that were used are very inadequate and misleading.

This is not the first RFC that represents a republication of
a standard controlled by a different standardization body
or private entity.

Just use something like your explanation instead, and
it will likely have the desired effect on the comments
you receive for this document.

Random other example for how other RFCs have done this:

RFC-2986 (PKCS-10) http://tools.ietf.org/html/rfc2986

  Abstract

  This memo represents a republication of PKCS #10 v1.7 from RSA
  Laboratories' Public-Key Cryptography Standards (PKCS) series, and
change control is retained within the PKCS process. The body of this
  document, except for the security considerations section, is taken
  directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document.



I do understand that the structure and the style of these
documents are unfamiliar to the significant part of
community, but this is because of the fact it is
_a_translation_ of official standard text.
It is not a retelliing or compilation, it is a _translation_.

And it is intended to exist as a reference to the  origin,
when creating further IETF documents, which will be pure IETF
documents and will be commented and edited when necessary.


A republication only makes sense if it is sufficient to
understand and implement the technology.  If you respond
to a request for clarification with

"because it is obvious from standard procedure of
certification in Russia."

then there may be a significant misunderstanding about
the purpose of informational RFC documents.  That only
makes sense if it is sufficiently complete and clear
to allow for independent interoperable implementations
of IETF protocols.


-Martin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>