From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Wed Jul 2 16:35:29 2003 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 QAA13828 for ; Wed, 2 Jul 2003 16:35:25 -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 h62KXrw14132 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 2 Jul 2003 16:33:55 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h62KZ1I22326 for ipseckey-outgoing; Wed, 2 Jul 2003 16:35:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h62KYv222321 for ; Wed, 2 Jul 2003 16:34:58 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12646; Wed, 2 Jul 2003 16:32:13 -0400 (EDT) Message-Id: <200307022032.QAA12646@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipseckey@sandelman.ca From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [IPSECKEY] I-D ACTION:draft-ietf-ipseckey-rr-05.txt Date: Wed, 02 Jul 2003 16:32:13 -0400 Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPSEC KEYing information resource record Working Group of the IETF. Title : A method for storing IPsec keying material in DNS Author(s) : M. Richardson Filename : draft-ietf-ipseckey-rr-05.txt Pages : 15 Date : 2003-7-2 This document describes a new resource record for DNS. This record may be used to store public keys for use in IPsec systems. This record replaces the functionality of the sub-type #1 of the KEY Resource Record, which has been obsoleted by RFC3445. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipseckey-rr-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipseckey-rr-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipseckey-rr-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-2161524.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipseckey-rr-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipseckey-rr-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2161524.I-D@ietf.org> --OtherAccess-- --NextPart-- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Wed Jul 9 15:37:42 2003 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 PAA17419 for ; Wed, 9 Jul 2003 15:37:40 -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 h69JZAX17404 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 9 Jul 2003 15:35:11 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h69JaFU21319 for ipseckey-outgoing; Wed, 9 Jul 2003 15:36:15 -0400 (EDT) Received: (from mcr@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h69JaD921313 for ipseckey@sandelman.ca; Wed, 9 Jul 2003 15:36:13 -0400 (EDT) From: Michael Richardson Message-Id: <200307091936.h69JaD921313@lox.sandelman.ottawa.on.ca> Subject: [IPSECKEY] agenda To: ipseckey@sandelman.ca Date: Wed, 9 Jul 2003 15:36:13 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca Content-Transfer-Encoding: 7bit I guess we do not have a schedule slot. I think we were in WG last call? - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Mon Jul 14 11:12:51 2003 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 LAA27636 for ; Mon, 14 Jul 2003 11:12:49 -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 h6EFAOW09481 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Mon, 14 Jul 2003 11:10:27 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h6EFBkc07594 for ipseckey-outgoing; Mon, 14 Jul 2003 11:11:46 -0400 (EDT) Received: from ogud.com (pcp04400154pcs.nrockv01.md.comcast.net [69.140.166.204]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h6EFBic07587 for ; Mon, 14 Jul 2003 11:11:44 -0400 (EDT) Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p1/8.12.8) with ESMTP id h6EF8Sue066683; Mon, 14 Jul 2003 11:08:29 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20030713171053.026b87e0@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 14 Jul 2003 11:09:39 -0400 To: Sam Weiler , From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: [IPSECKEY] IPSECKEY inheritance of DNSSEC algorithm registry Cc: ipseckey In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca At 19:00 2003-06-17, Sam Weiler wrote: >The IPSECKEY RR definition draft is nearing WG last call -- this would >be a good time to review the document. > >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? > >The text in draft-ietf-ipseckey-rr-04.txt is internally inconsistent, >but the intent with this version was that, yes, the formats are >inherited. To repeat what I said on June 19'th http://www.sandelman.ca/lists/html/ipseckey/msg00201.html There is no way to avoid having different registry, the main reason is we can not guarantee that one registry will contain all algorithms needed. For example IPSEC may adopt ECC while DNSSEC may not, thus IPSECKEY will not be able to inherit ECC wire format from DNS. The format of the registry can be quite simple, IPSECKEY registry entry for algorithm N is that wire format is identical as specified in RFCxxxx section yy. The same comment applies to the registry for DNSKEY in the type code rollover, so that document needs updated IANA considerations section. Olafur - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From mcr@lox.sandelman.ottawa.on.ca Tue Jul 15 11:47:08 2003 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 LAA24846 for ; Tue, 15 Jul 2003 11:47:08 -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 h6FFkhE16053 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Tue, 15 Jul 2003 11:47:10 -0400 (EDT) Received: (from mcr@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h6FFkfW18958; Tue, 15 Jul 2003 11:46:41 -0400 (EDT) Date: Tue, 15 Jul 2003 11:46:41 -0400 (EDT) Message-Id: <200307151546.h6FFkfW18958@lox.sandelman.ottawa.on.ca> From: mcr@sandelman.ottawa.on.ca Subject: [ipseckey] Monthly information file for ipseckey@sandelman.ottawa.on.ca To: ipseckey-archive@ietf.org BOF description IPSEC KEYing information resource record WG (ipseckey) Please see http://www.ietf.org/html.charters/ipseckey-charter.html for the official page. To unsubscribe, email to majordomo@sandelman.ca, body is: "unsubscribe ipseckey" You can always ask majordomo@sandelman.ottawa.on.ca to remove you from any list hosted by Sandelman Software This message sent to ipseckey-archive@lists.ietf.org From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Sun Jul 27 19:18:40 2003 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 TAA28475 for ; Sun, 27 Jul 2003 19:18:31 -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 h6RNDKW18178 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Sun, 27 Jul 2003 19:13:22 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h6RNFdN23540 for ipseckey-outgoing; Sun, 27 Jul 2003 19:15:39 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h6RNFbM23534 for ; Sun, 27 Jul 2003 19:15:37 -0400 (EDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h6RNCIW18175 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Sun, 27 Jul 2003 19:12:24 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h6RNDaO9014076 for ; Sun, 27 Jul 2003 19:13:36 -0400 To: ipseckey@sandelman.ca Subject: [IPSECKEY] new registry text Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sun, 27 Jul 2003 19:13:36 -0400 Message-ID: <14075.1059347616@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- My web site, www.sandelman.ca/SSW/ietf/ipsec/key/ contains an -06 revision that I have asked the ID editor to publish. Relevant changed text: 2.3 RDATA format - algorithm type 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. | A value of 0 indicates that no key is present. | The following values are defined: | 1 A DSA key is present, in the format defined in RFC2536 [10] | 2 A RSA key is present, in the format defined in RFC3110 [11] |2.6.1 Example: RSA public keys | An algorithm type of 2 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. | The earlier definition of RSA/MD5 in RFC2065 limited the exponent and | modulus to 2552 bits in length. RFC3110 extended that limit to 4096 | bits for RSA/SHA1 keys. 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. ... 5. IANA Considerations This document updates the IANA Registry for DNS Resource Record Types by assigning type X to the IPSECKEY record. | This document creates an IANA registry for the algorithm type field. | The algorithm field has assigned values 0, 1 and 2. Algorithm | numbers 3 through 255 can be assigned by IETF Consensus (see RFC2434 | [5]). ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ |Richardson Expires January 25, 2004 [Page 11] |Internet-Draft ipsecrr July 2003 6. Acknowledgments | My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob | Austein, and Olafur Gurmundsson who reviewed this document carefully. | Additional thanks to Olafur Gurmundsson for a reference | implementation. |Richardson Expires January 25, 2004 [Page 12] |Internet-Draft ipsecrr July 2003 Normative references [1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [4] Eastlake, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997. | [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA | Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. |Richardson Expires January 25, 2004 [Page 13] |Internet-Draft ipsecrr July 2003 Non-normative references | [6] Thomson, S. and C. Huitema, "DNS Extensions to support IP version 6", RFC 1886, December 1995. | [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. | [8] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. | [9] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. | [10] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, March 1999. | [11] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, May 2001. | [12] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource Record (RR)", RFC 3445, December 2002. Author's Address Michael C. Richardson Sandelman Software Works 470 Dawson Avenue Ottawa, ON K1Z 5V7 CA EMail: mcr@sandelman.ottawa.on.ca URI: http://www.sandelman.ottawa.on.ca/ |Richardson Expires January 25, 2004 [Page 14] |Internet-Draft ipsecrr July 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. |Richardson Expires January 25, 2004 [Page 15] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBPyRcnoqHRg3pndX9AQHT+QP+NLTsJuljaWG/UYGZkvXrjwCZ0E60jeiP YhSc82dzau+JDxI9Pp3jn3VIQMEQz9CIzBN8Hm4FKIE7UYa58Afwgenv7p69Zsu9 Z4okJI2njenzQPOcuLkXnlLYUUeSHJCMdaWX7oImnCt7LhMyKpnnzZrm2CP3r7tG g8xF4CE8R84= =d/7j -----END PGP SIGNATURE----- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed.