[prev in list] [next in list] [prev in thread] [next in thread] 

List:       namedroppers
Subject:    Re: rfc2538bis IANA considerations
From:       Samuel Weiler <weiler () tislabs ! com>
Date:       2005-03-22 21:59:36
Message-ID: Pine.GSO.4.55.0503221649150.23573 () filbert
[Download RAW message or body]

I think there are two remaining open questions related to the CERT RR
and the DNSSEC algorithm number registry.  Any input?  Do we want to
allow CERT RRs to contain ALL algorithm types specified in this
registry, or do we want to add another applicability list?

> > -- 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.
>
> I have no idea how to address this, nor can I answer the question.  I
> hope that others will give input on this.
>
> > -- 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?
>
> It seem to require some work for new algorithm definers.  My
> experience is that the key tag and algorithm fields of CERT RRs are
> rarely useful, nor consistently populated.  So the additional work
> will lead to little practical advantage, in my opinion.  That would
> suggest we shouldn't worry about this.
>
> However, this seem to be more of a process issue, than a technical
> concern, so I'd be interested to hear what others feel.

And then there's the straight-forward IANA text:

> > -- 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.
>
> Do you think anything should go into 2538bis to achieve this?

Yes, how about adding to the IANA section of 2538bis:

"The CERT RR reuses the DNS Security Algorithm Numbers registry.  In
particular, the CERT RR requires that algorithm number 0 remain
reserved, as described in Section 2.  The IANA is directed to
reference the CERT RR as a user of this registry and value 0, in
particular."

It's a shame we have to do this explicitly, but emails to IANA about
it just haven't been answered.

Perhaps the below could be sent to IANA out-of-band, too:

> >    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 namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
[prev in list] [next in list] [prev in thread] [next in thread]