Re: draft-ietf-dnsext-dnssec-gost

Martin Rex <mrex@sap.com> Sat, 13 February 2010 02:50 UTC

Return-Path: <mrex@sap.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1078D28C258 for <ietf@core3.amsl.com>; Fri, 12 Feb 2010 18:50:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.212
X-Spam-Level:
X-Spam-Status: No, score=-10.212 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXkE8beqJQTO for <ietf@core3.amsl.com>; Fri, 12 Feb 2010 18:50:30 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id E403F28C222 for <ietf@ietf.org>; Fri, 12 Feb 2010 18:50:29 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o1D2plmV004646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Feb 2010 03:51:47 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201002130251.o1D2pjGt012896@fs4113.wdf.sap.corp>
Subject: Re: draft-ietf-dnsext-dnssec-gost
To: dol@cryptocom.ru
Date: Sat, 13 Feb 2010 03:51:45 +0100
In-Reply-To: <4B7542E3.1030404@cryptocom.ru> from "Basil Dolmatov" at Feb 12, 10 03:00:35 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Feb 2010 02:50:31 -0000

Basil Dolmatov wrote:
> 
> Martin Rex пишет:
> > 
> > Whether and how much the -1994 version is
> > deprecated is also a complete mystery.  
>
> It is written in the text of GOST -2001

Which document are you refering to when you say "text of GOST -2001" ?


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.


> 
> 
> >  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.
> 
> No certificate can be issued for any hardware/software using -1994 
> algorithm after 12.09.2001 and the certification period is 3 years.
> 
> So, after 12.09.2004 there can be no operating hardware/software using 
> -1994 algorithm.


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


I just found the following paragraph in the Copyright Notice of

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

on the title page which irritates me:

   This document may not be modified, and derivative works of it may
   not be created, except to format it for publication as an RFC or to
   translate it into languages other than English.


Is there a new trend to have the IETF rubber stamp documents as is?

To me, this statement precludes editorial changes/corrections,
which doesn't sound right.

I boldly assumed the original name of the IETF documents "RFC"
mean "Request For Comment", in the form that the community was
asked for feedback (request for clarifications, correction or
changes) before document was published.

At least this is how I understand "The Tao of the IETF"

http://tools.ietf.org/html/rfc4677#section-8.1


Although the IETF may not have "change control" for the technical
contents described in informational document, a complete absence
of change control of document structure, clarity, detail of
explanation and editorial issues would come as a suprise to me...


-Martin