Subject: Keeping the KEY and SIG typecodes active

From: "Scott Rose" <[email-masked]>
Date: Tue, 17 Jun 2003 16:01:14 -0400

Not given a DNSSECbis Question number, as it isn't a DNSSEC question per se.
This came up at a meeting on Friday over wildcards, CNAME, and some corner
cases in DNSSEC at Olafur's house. The idea of removing the subtyping of
DNSKEY to be both zone keys and entity keys came up. The idea is to keep the
KEY RR for transaction authentication (entity keys) and DNSKEY for zone
keys.

Topic: Keeping the KEY (typcode 24) and SIG (25) for transaction
authentication only.

With the typecode rollover of the KEY RR to the DNSKEY RR, we are left with
a three typecodes now retired. However, there is still a viable currently
deployed codebase and use for these record types.

The KEY RR would continue to be used for transaction authentication key
storage only (SIG(0) validating keys, TKEY operations). SIG would be used
only for SIG(0) operations. The only change that is necessary is that
servers/resolvers that use the new typecodes should recognize the old
typcodes in these functions.

The format of these records will remain largely unchanged from their current
specification. The KEY RR will be regarded as any other data RR with regards
to handling and placement in a zone. The definitions of the KEY RDATA fields
will be:

Flags: All flag bits are RESERVED and MUST be zero (especially bit 7, the
zone key bit). Changes to flag bit definition must be done by IETF
consensus.

Protocol field: MUST be 3 (old DNSSEC).

All other fields remain as they are described in RFC 2535 and subsequent
updates.

The SIG RR will remain as described in RFC's 2535, 2931 and 3008

Currently deployed code that recognizes and handles SIG(0)'s will be able to
function as before. New servers that see the new typecodes (DNSKEY, RRSIG,
etc) that choose to support SIG(0) MUST also be able to process the KEY and
SIG RRs during transaction authentication.

This will not go into the DNSSECbis specification drafts, as they deal with
transaction authentication, which is not one of the goals stated in the
DNSSEC specification. This will either be a new draft, or rolled into Sam
Weiler's typecode rollover draft.

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