Subject: [dnsext] I-D Action:draft-ietf-dnsext-dnssec-registry-fixes-00.txt

From: [email-masked]
Date: Wed, 14 Oct 2009 11:15:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title           : DNS Security (DNSSEC) DNSKEY IANA Registry Algorithm Status Addition
	Author(s)       : S. Rose
	Filename        : draft-ietf-dnsext-dnssec-registry-fixes-00.txt
	Pages           : 6
	Date            : 2009-10-14

The DNS Security Extensions (DNSSEC) has an IANA registry to allocate
cryptographic algorithm suites for use in generating digital
signatures over DNS data.  Newly introduced cryptographic algorithms
to DNSSEC mean implementors need to know which algorithms need to be
implmented, which are optional, and which are obsolete.  This
document adds a column to the IANA registry table for Domain Name
System Security (DNSSEC) Algorithm Numbers to list their status for
use.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-registry-fixes-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 14 Oct 2009 14:05:52 -0700

There is a major unstated premise of this document. It assumes, without saying, that the MANDATORY / OPTIONAL / OBSOLETE status of a signature algorithm is determined by RFC 4034.

If the document said "these status are derived from RFC 4034", and if the added column said "Status from RFC 4034", it would fix the problem.

However, the last paragraph of section 2 says:
   Newly allocated algorithms will need to state their intended status
   in their specification.  Any changes to a previously allocated
   algorithm's status MUST be done by a standards track document.
That is quite troubling. If the new RFC updates 4034, then the status change comes from the update to 4034, not from the existence of the new doc. If the new RFC does not update 4034, then the IANA registry's value goes to hell quickly.

A way to fix this would be to state "the only way to make a signature algorithm mandatory or obsolete is to update RFC 4034; the IANA registry can be updated at the same time as the update to RFC 4034 is published".

--Paul Hoffman, Director
--VPN Consortium