Re: draft-ietf-dnsext-dnssec-gost

[Phillip Hallam-baker <[e-mail]>]

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" <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf