[IPSECKEY] Generic algorithm test
Sam Weiler <weiler@watson.org> Thu, 05 June 2003 03:10 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 XAA23923 for <ipseckey-archive@lists.ietf.org>; Wed, 4 Jun 2003 23:10:13 -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 h5536EH23376 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 4 Jun 2003 23:06:16 -0400 (EDT)
Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h5537Y403261 for ipseckey-outgoing; Wed, 4 Jun 2003 23:07:34 -0400 (EDT)
Received: from fledge.watson.org (ak82hjs7hex92j@fledge.watson.org [204.156.12.50]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h5537Wm03241 for <ipseckey@lox.sandelman.ottawa.on.ca>; Wed, 4 Jun 2003 23:07:32 -0400 (EDT)
Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9/8.12.9) with ESMTP id h5534uOn010697; Wed, 4 Jun 2003 23:04:56 -0400 (EDT) (envelope-from weiler@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.12.9/8.12.9/Submit) with SMTP id h5534t8l010694; Wed, 4 Jun 2003 23:04:55 -0400 (EDT) (envelope-from weiler@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Wed, 04 Jun 2003 23:04:55 -0400
From: Sam Weiler <weiler@watson.org>
Reply-To: Sam Weiler <weiler@watson.org>
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
cc: ipseckey <ipseckey@lox.sandelman.ottawa.on.ca>
Subject: [IPSECKEY] Generic algorithm test
In-Reply-To: <Pine.NEB.3.96L.1030530154045.60084H-100000@fledge.watson.org>
Message-ID: <Pine.NEB.3.96L.1030604230133.8368A-100000@fledge.watson.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-ipseckey@sandelman.ottawa.on.ca
Precedence: bulk
X-List: ipseckey@sandelman.ottawa.on.ca
On Fri, 30 May 2003, Sam Weiler wrote: > > Sam> Section 2.4: Needs to have generic text for any value, then the > > Sam> expansion for RSA and maybe mention the DSA doc, but not in it's own > > Sam> subsection. > > This is now 2.6/2.7. The new section 2.3 isn't clear on how (or if) > IPSECKEY automatically incorporates newly defined public key formats. > This needs to be clarified. > > 2.6 Should have generic text specifying how any key format is included, > with RSA and DSA given as examples, assuming that we want this to be > extensible. If we want to limit it to RSA/DSA, that should be made more > explicit. I've been having second thoughts about the wisdom of inheriting from the DNS Algorithm registry. Are all of the defined alogirthm types appropriate for IPSECKEY use? Is it likely that future ones will be? Remember that DNSSEC algorithms specify a hash, too, which is why RSA/MD5 and RSA/SHA1 have different algorithm values even though the data format is exactly the same. Do we want to prohibit use of type 1 (RSA/MD5)? What about the private formats? Assuming that inheritance is desired, here's some proposed text: RFC2535 established an IANA registry for DNS Security Algorithm Numbers, and subsequent documents have specified algorithms and associated KEY RR formats for use with DNSSEC. Rather than respecify those formats, this document reuses that registry and the associated KEY RR formats. The algorithm type field identifies the public key's cryptographic algorithm and determines the format of the public key field. 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. Example: RSA public keys Per the DNS Security Algorithm registry, an algorithm type of 5 identifies an RSA public key, encoded as described in section 2 of RFC3110. [The encoding of RSA/MD5 KEYs (type 1) specified in RFC2537 is the same as that defined in RFC3110. For simplicity and in keeping with RSA/MD5 being NOT RECOMMENDED for DNSSEC, type 1 SHOULD NOT be used in the IPSECKEY algorithm type.] The earlier definition of RSA/MD5 (algorithm type 1) in RFC2065 limited the exponent and modulus to 2552 bits in length. RFC3110 extended that limit to 4096 bits for RSA/SHA1 keys (type 5). The IPSECKEY RR imposes no length limit on type 5 public keys, other than the 65535 octet limit imposed by the two-octet length encoding. This length extension is applicable only to IPSECKEY and not to KEY RRs. And in the IANA considerations: This document updates the IANA Registry for DNS Resource Record Types by assigning type X to the IPSECKEY record. The values for the algorithm type field in the IPSECKEY record are inherited from the DNS Security Algorithm Numbers registry, and this document makes no changes to that registry. - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed.
- [IPSECKEY] Generic algorithm test Sam Weiler
- Re: [IPSECKEY] Generic algorithm test Michael Richardson
- Re: [IPSECKEY] Generic algorithm test Michael Richardson
- Re: [IPSECKEY] Generic algorithm test Ólafur Guðmundsson