Subject: rfc2538bis IANA considerations

From: Samuel Weiler <[email-masked]>
Date: Thu, 27 Jan 2005 17:02:38 -0500 (EST)

All-in-all, I think 2538bis is in good shape.  I sent some editorial
comments to Simon.  Here are some slightly more substantive ones re:
algorithm numbers.

On Fri, 5 Nov 2004, Samuel Weiler wrote:

> > If I remember correctly, RFC 2538 uses the same IANA name space as the
> > rest of DNSSEC for the key algorithms.  Perhaps someone is using ECC
> > for X.509 or OpenPGP data.  So a specification for ECC, and an entry
> > in the IANA DNSKEY key algorithm registry, seem useful.
>
> I'm surprised that no one caught this when we were bickering over the
> RFC3755 IANA registry format.  I don't have any problems with CERT
> reusing the registry, but as you're working on 2538bis, you might want
> to check the IANA considerations section in 3755 and the registry
> itself to see if any changes are needed.  2538bis might want to cite
> 3755, too.  In any case, I think it would be good to add a note in the
> registry mentioning that CERT uses these numbers, also:
>
> http://www.iana.org/assignments/dns-sec-alg-numbers

To avoid confusing future users of the algorithm registry, I suggest:

-- Ask IANA to add a citation to 2538bis for algorithm 0 -- it's
   already marked reserved, but 2538 explains why it needs to
   remain reserved.  You might even rename it to 'CERT RR private'
   or somesuch.

-- Ask IANA to add the CERT RR to the list of type codes that use this
   registry.  That may encourage the next fool who comes along and
   wants to change or reuse the registry to remember CERT, as we
   forgot to do in 2004.

-- Can CERTs use private algorithms (type 253/254)?  If so, do you
   still want to use the same encoding as for KEY/DNSKEY, with the
   algorithm in the RDATA?  Some explicit mention of the private
   algorithms might be a good idea, in any case.  Also note David
   Blacka's DNSSEC experiment draft, which encourages use of
   the private algorithms.

-- Given that 3755 added applicablility columns to the algorithm
   registry (see the registry itself and 3755 for details), do you
   want another column for CERT, along with a requirement that new
   algorithm definitions say whether they can be used for CERTs or
   not?  If you want to reuse all algorithms registers, the doc should
   say that (and the registry probably should, too).  Suggested
   registry text for the 'reuse all' option might be:

OLD:  The KEY, SIG, DNSKEY, RRSIG, and DS RRs use an 8-bit number used
      to identify the security algorithm being used.

      Some algorithms are usable only for zone signing (DNSSEC), some
      only for transaction security mechanisms (SIG(0) and TSIG), and
      some for both.  Those usable for zone signing may appear in
      DNSKEY, RRSIG, and DS RRs.  Those usable for SIG(0) and TSIG may
      appear in SIG and KEY RRs.

NEW:  The KEY, SIG, DNSKEY, RRSIG, DS, and CERT RRs use an 8-bit
      number used to identify the security algorithm being used.

      All algorithm numbers in this registry may be used in CERT RRs.
      Some algorithms are not usable for zone signing (DNSSEC) and
      some are not usable for transaction security mechanisms (SIG(0)
      and TSIG).  Only those usable for zone signing may appear in
      DNSKEY, RRSIG, and DS RRs.  Only those usable for SIG(0) and
      TSIG may appear in SIG and KEY RRs.

-- 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/>