RE: draft-ietf-dnsext-dnssec-gost

["Rex, Martin" <[e-mail]>]

 

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