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.
- [IPSECKEY] IPSECKEY inheritance of DNSSEC algorit… Sam Weiler
- Re: [IPSECKEY] IPSECKEY inheritance of DNSSEC alg… Pekka Nikander