Re: [IPSECKEY] IPSECKEY inheritance of DNSSEC algorithm registry

Pekka Nikander <pekka.nikander@nomadiclab.com> Wed, 18 June 2003 09:54 UTC

Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25458 for <ipseckey-archive@lists.ietf.org>; Wed, 18 Jun 2003 05:54:28 -0400 (EDT)
Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h5I9rWq21266 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 18 Jun 2003 05:53:34 -0400 (EDT)
Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h5I9sfI14224 for ipseckey-outgoing; Wed, 18 Jun 2003 05:54:41 -0400 (EDT)
Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h5I9saV14207 for <ipseckey@lox.sandelman.ottawa.on.ca>; Wed, 18 Jun 2003 05:54:36 -0400 (EDT)
Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 9C5101C; Wed, 18 Jun 2003 13:02:38 +0300 (EEST)
Message-ID: <3EF036B2.5000508@nomadiclab.com>
Date: Wed, 18 Jun 2003 12:53:54 +0300
From: Pekka Nikander <pekka.nikander@nomadiclab.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sam Weiler <weiler@tislabs.com>
Cc: namedroppers@ops.ietf.org, ipseckey <ipseckey@lox.sandelman.ottawa.on.ca>
Subject: Re: [IPSECKEY] IPSECKEY inheritance of DNSSEC algorithm registry
References: <Pine.GSO.4.33.0306171421200.11723-100000@raven>
In-Reply-To: <Pine.GSO.4.33.0306171421200.11723-100000@raven>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Sender: owner-ipseckey@sandelman.ottawa.on.ca
Precedence: bulk
X-List: ipseckey@sandelman.ottawa.on.ca
Content-Transfer-Encoding: 7bit

Sam Weiler wrote:

> The chairs would particularly like feedback on whether or not the
> IPSECKEY record should inherit format definitions from the DNS
> Security Algorithm registry -- if someone defines a (DNS)KEY RR format
> for Sam's Public Key Algorithm, does it automagically show up as an
> IPSECKEY format?

I am in favour of inheriting the definitions.  The same definitions
are currently being reused in HIP, and I am proposing that we use
those also in SEND.  (SEND currently specifies ASN.1 OIDs, but I
personally see little value in that.)

In particular, what comes to the following:

> 2.3 RDATA format - algorithm type
> 
....
>    The public key field contains the algorithm-specific portion of the
>    KEY RR RDATA, omitting the first four octets of the KEY RR RDATA.
>    This is the same portion of the KEY RR that must be specified by
>    documents that define a DNSSEC algorithm.  Those documents also
>    specify a message digest to be used for generation of SIG RRs; that
>    specification is not relevant to the IPSECKEY usage of the public key
>    format.

I think the intention of the text is excellent.  It aligns very
well with the current HIP usage of RFC2535 key formats.  However,
it might be good to explicitly mention that the first four octets
would contain the flags, protocol, and algorithm fields, which
are now left away.

A couple of comments:

   Should there be a reserved octed before the gateway field,
   thereby aligning the gateway field to 32-bit boundary?

   AAAA RDATA format is defined in Section 2.2 (not 3.2) of RFC1886.

--Pekka Nikander

-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.