Subject: Re: New IANA considerations for Typecode-rollover-05

From: Samuel Weiler <[email-masked]>
Date: Sun, 9 Nov 2003 17:23:42 -0500 (EST)

This attempts to force algorithms to use the same number across
functions, which tcr-05 does informally with the phrase:
"... suggested, but not required, that it be assigned the same number
in both registries".

That's a fine idea, but actually copying the registry data around
seems certain to lead to confusion, particularly if we say that the
algorithm numbers may be changed during the copying.

If the WG really wants to go this route, I suggest making the current
registry generic and adding applicability list registries.  As in:

   The "DNS Transaction Security Algorithm Applicability" registry
   lists those algorithms from the "DNS Security Algorithm Numbers"
   registry that are usable by the DNS transaction security mechanims
   (SIG(0) and TKEY) and, in particular, usable in KEY and SIG
   records.  It initially includes algorithm numbers 1, 2, 3, 5, 252,
   253, and 254.

Personally, I think tcr-05's solution is adequate, particularly if the
relevant sentence is copied into the registries to remind IANA of what
to do.  I'd be happy to consider some stronger text in that paragraph,
if anyone has something to suggest.  As in: "If an algorithm is
defined in only one registry, it is suggested that the number assigned
to it not be assigned in the other registry."

Furthermore, the proposed text misstates the current assignments (it
misses Indirect and the ECC reservation) and doesn't add the mnemonics
to the registry, which TCR-05 tries to fix.

-- Sam

--
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: Samuel Weiler <[email-masked]>
Date: Wed, 12 Nov 2003 21:37:09 -0500 (EST)

Here's a possible TCR IANA section that makes the existing registry
generic and adds two applicability lists.  Again, I'd rather keep the
TCR-05 solution, but I prefer the below to having a no-op registry
that other registries may copy, copy with changes, or even ignore.

Comments?  Is the TCR-05 solution adequate?  Do we need this?

   This document updates the IANA registry for DNS Resource Record
   Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and
   DNSKEY RRs, respectively.

   Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and
   TKEY [RFC2930] use only.  Type 30 (NXT) should be marked as
   Obsolete.

   In order to allow zone signing (DNSSEC) and transaction security
   mechanisms (SIG(0) and TKEY) to use different sets of algorithms
   and key formats, the existing "DNS Security Algorithm Numbers"
   registry will become a generic registry that isn't specific to any
   RR type.

   Two new registries are created, "DNS Transaction Security Algorithm
   Applicability" and "DNS Zone Signing Algorithm Applicability".
   (Alternate names: "KEY and SIG Algorithm Applicability" and
   "DNSKEY, DS, and RRSIG Algorithm Applicability") Each requires IETF
   Standards Action to change.

   "DNS Transaction Security Algorithm Applicability" lists those
   algorithms from the "DNS Security Algorithm Numbers" registry that
   are usable by the DNS transaction security mechanims (SIG(0) and
   TKEY) and, in particular, usable in KEY and SIG records.  It
   initially includes algorithm numbers 1, 2, 3, 5, 252, 253, and 254.

   "DNS Zone Signing Algorithm Applicability" lists those algorithms
   from the "DNS Security Algorithm Numbers" registry that are usable
   for zone signing, and, in particular, the DNSKEY, DS, and RRSIG
   records.  It initially includes algorithm numbers 2, 3, 5, 253, and
   254.

   Additionally, presentation format mnemonics as defined in RFC2535
   Section 7 are added to the "DNS Security Algorithm Numbers"
   registry.  This document assigns RSA/SHA-1 (type 5) the mnemonic
   RSASHA1.  As in RFC2535, IETF Standards Action is required to change
   this registry.  At this time, values 4 and 6-251 are available for
   assignment, with 4 reserved for eliptic curve keys.

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 12 Nov 2003 22:18:58 -0500

This means there will be 3 registries for algorithm codes?  (did I read that
right?)  If so, that seems a bit excessive since the 2 new registries get
their values from the base registry.

Scott

Oh, and is the "trivial bug" in the -05 TCR draft the fact that you mention
SIG RRs might be present in a zone (covered by a RRSIG)?  Why would a SIG(0)
RR have a RRSIG?  ;-)