Subject: [dnsext] Adopting GOST digital signature algorithm document

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Fri, 15 May 2009 14:33:55 -0400

On April 13'th 2009 the chairs asked the WG about adoption of
         draft-dolmatov-dnsext-gost-dnssec-00.txt
         http://psg.com/lists/namedroppers/namedroppers.2009/msg00422.html

5 people stated that they supported the adoption of the document:
         Paul Hoffman, Edward Lewis, Ondrej Sury, Sam Weiler and
         Wouter Wijngaards
There were other people that voiced opposition to the draft.
Thus the draft meets the criteria for adoption.

The chairs also asked for opinions from the CFRG mailing list:
         http://www.irtf.org/mail-archive/web/cfrg/current/msg02612.html
At this point no conclusion can be drawn from the discussion there.

The current DNSKEY registry
         <http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml>http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml 

states that the criteria for adding a new algorithm is IETF standards action.
This means DNSEXT is the ONLY conduit for new algorithms.
The same goes for the DS digest.

During the discussion on the mailing list there was some discussion 
on what criteria
to use for adoption of new algorithms and the status of different algorithms.
Currently the registry has two states, 'allowed to sign zone' Y/N.
Some people have stated to the Chairs (on and off-list) that they have no
objection to registering new algorithms if algorithms can be marked 
as "optional".
Currently the WG has no policy on accepting or refusing adding new algorithms.

Sam Weiler pointed out that the draft is proposing adding a new
NSEC3 obfuscating function:
         http://psg.com/lists/namedroppers/namedroppers.2009/msg00503.html
Defining such a function has a high threshold as RFC5155 requires
that the next obfuscating function needs to offer algorithm agility
and specify the transition in a zone between obfuscation functions.

Due to the importance for Russia to be able to use a standard DNSSEC 
algorithm soon
the Chairs' conclusion:
A document containing:
         - DNSKEY GOST R 34.10-2001 with GOST R 34.11-94 registration
         - DS GOST R 34.11-94 registration
will be adopted as a WG document.

Due to the restricted charter, adding this document will require a 
charter update.
The chairs plan to submit a new charter late next week that includes 
charter changes
required by this document and any forgery resilience documents.

Any NSEC3 obfuscation function specification must be separated into a
different document.
If such a document is submitted, the Chairs will issue a separate call
for adoption for that document.

         Olafur (and Andrew) 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: [email-masked]
Date: Fri, 15 May 2009 19:23:41 +0000

thank you... i look forward to lively debate.

--bill