From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Thu Mar 13 19:04:41 2003 Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h2E04f514163 for ipseckey-outgoing; Thu, 13 Mar 2003 19:04:41 -0500 (EST) 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 h2E04d314152 for ; Thu, 13 Mar 2003 19:04:39 -0500 (EST) Received: from thrintun.hactrn.net ([2002:425c:4242:0:250:daff:fe82:1c39]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h2E04AD20484 for ; Thu, 13 Mar 2003 19:04:12 -0500 (EST) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 833DD18ED; Thu, 13 Mar 2003 19:03:57 -0500 (EST) Date: Thu, 13 Mar 2003 19:03:56 -0500 From: Rob Austein To: agenda@ietf.org, ipseckey@sandelman.ca Cc: "Steven M. Bellovin" , Sam Weiler Subject: [IPSECKEY] IPSECKEY agenda MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030314000357.833DD18ED@thrintun.hactrn.net> Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca IETF 56, San Francisco IPSECKEY WG Tuesday 18 March 2003 17:00-18:00 AGENDA 17:00 Pressgang scribes Blue sheets and other adminstrivia Are there alternate proposals? Bash agenda 17:05 draft-richardson-ipsec-rr-02.txt Does the WG accept this as a WG document? Any further comments about technical issues in current draft? What's missing from this draft? Anything it'd be useful to add now that we're no longer talking about retrofitting stuff into the old KEY RR? 17:30 Any other business, including alternate proposals? If there's nothing to fill this slot, previous topic can have this time too. 17:50 Wrap-up: what do we do next, either to deliver per the milestones on our charter or to adjust them if we realize that they're now wrong. 18:00 Adjourn - 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 Mar 17 18:09:34 2003 Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h2HN9Y526220 for ipseckey-outgoing; Mon, 17 Mar 2003 18:09:34 -0500 (EST) 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 h2HN9WJ26215 for ; Mon, 17 Mar 2003 18:09:32 -0500 (EST) Received: from sandelman.ottawa.on.ca (wl-193-246.wireless.ietf56.ietf.org [130.129.193.246] (may be forged)) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h2HN8vD07048 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Mon, 17 Mar 2003 18:09:01 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1] (may be forged)) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h2HN8tMc010618 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 17 Mar 2003 15:08:56 -0800 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-5) with ESMTP id h2HN8tha010614 for ; Mon, 17 Mar 2003 15:08:55 -0800 Message-Id: <200303172308.h2HN8tha010614@marajade.sandelman.ottawa.on.ca> To: ipseckey Subject: [IPSECKEY] revision -03 Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 17 Mar 2003 15:08:55 -0800 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- I've done a -03 revision, from comments from Mark Andrews. It is at: http://www.sandelman.ca/SSW/ietf/ipsec/key/ Major changes: 1) gateway field is not a string, but a wire-encoded domain-name. 2) as a result, the domain-name has a self-describing length, 3) so the public key length has been removed. 4) the @domain and user@domain notation has been removed. ] ON HUMILITY: to err is human. To moo, bovine. | 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 Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPnZVhYqHRg3pndX9AQFIygP/c3S4LhUJa/mAk8/KCW5+7klPX5MnrZ3S hrOO3BUE7DOjEinDewYV6dW2thDds98n2wTIkJnnw8ZkR6fNEXkcWU6ktiqVQv4M XKVVuwnr0SQTV5sUyEAqgOy9BvHuEFmkPUjv7SdLmpMW07eTXe6aU4k9Ybq3gBqc 0YEEreotYeY= =DJLj -----END PGP SIGNATURE----- - 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 Tue Mar 18 06:16:23 2003 Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h2IBGNp13852 for ipseckey-outgoing; Tue, 18 Mar 2003 06:16:23 -0500 (EST) Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h2IBGKo13846 for ; Tue, 18 Mar 2003 06:16:21 -0500 (EST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 48EAB3F75A for ; Tue, 18 Mar 2003 12:36:31 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003031812153317776 for ; Tue, 18 Mar 2003 12:15:33 +0100 Received: from cthulhu.int-evry.fr (ivan.int-evry.fr [157.159.100.48]) by sparte.int-evry.fr (Postfix) with ESMTP id B59C43F9CD for ; Tue, 18 Mar 2003 12:35:14 +0100 (CET) Received: from jjp by cthulhu.int-evry.fr with local (Exim 3.36 #1 (Debian)) id 18vF2Z-0006wt-00 for ; Tue, 18 Mar 2003 12:13:55 +0100 Date: Tue, 18 Mar 2003 12:13:55 +0100 From: Jean-Jacques Puig To: ipseckey Subject: [IPSECKEY] misc Message-ID: <20030318111355.GA26577@ivan.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.3i Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca Hello, It seems (to me) that the draft has reached a certain maturity. Being far from SF (and also timezonely phased out), I would be very pleased if someone could gave to the list a feedback about today's session (I mean, before a ``minutes'' digest if any :-). Is anyone aware of any informational documents or articles about considerations on the use of keys in the DNS system, from the point of view of replication/caching/revocation/propagation/... and some related recommended pratices ? Michael's mail in IPsec list (Me-Tarzan/You-Jane and key rollover) made me wonder if an in-depth study existed. BTW, is someone aware of any plans of development of OE patches for other opensource or free platforms than freeswan/linux ? Thx -- Jean-Jacques Puig - 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 Tue Mar 18 14:09:24 2003 Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h2IJ9O815398 for ipseckey-outgoing; Tue, 18 Mar 2003 14:09:24 -0500 (EST) 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 h2IJ9NS15393 for ; Tue, 18 Mar 2003 14:09:23 -0500 (EST) Received: from sandelman.ottawa.on.ca (wl-193-246.wireless.ietf56.ietf.org [130.129.193.246] (may be forged)) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h2IJ8mD10740 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 18 Mar 2003 14:08:51 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1] (may be forged)) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h2IJ8kAR021560 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 18 Mar 2003 11:08:47 -0800 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-5) with ESMTP id h2IJ8k0q021556 for ; Tue, 18 Mar 2003 11:08:46 -0800 Message-Id: <200303181908.h2IJ8k0q021556@marajade.sandelman.ottawa.on.ca> To: ipseckey Subject: Re: [IPSECKEY] misc In-reply-to: Your message of "Tue, 18 Mar 2003 12:13:55 +0100." <20030318111355.GA26577@ivan.int-evry.fr> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 18 Mar 2003 11:08:45 -0800 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jean-Jacques" == Jean-Jacques Puig writes: Jean-Jacques> It seems (to me) that the draft has reached a certain Jean-Jacques> maturity. Being far from SF (and also timezonely phased Jean-Jacques> out), I would be very pleased if someone could gave to the The session is this evening. Jean-Jacques> Is anyone aware of any informational documents or articles Jean-Jacques> about considerations on the use of keys in the DNS system, Jean-Jacques> from the point of view of Jean-Jacques> replication/caching/revocation/propagation/... and some We have thought about it a lot, but I'm not sure what you are asking for. Jean-Jacques> BTW, is someone aware of any plans of development of OE Jean-Jacques> patches for other opensource or free platforms than Jean-Jacques> freeswan/linux ? Please ask that question on design@lists.freeswan.org. ] ON HUMILITY: to err is human. To moo, bovine. | 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 Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPnduu4qHRg3pndX9AQEUKAQAnXTLUF6+JyIkwpSgT/os7bW0FeWD8dfD Nmz9+dpXAJD7s6m/av5ZrNMTUpjkJXTWQDOoUxXsQlRxGi1hXplV65W7P1sQnws6 m9ZtaAKzFwmVUXLyh7M8JB7YZmQGltSFgzHh7Gf0TSguGdRhMnUeSFjE8q/P96fy /6C85qfP5uw= =7cW/ -----END PGP SIGNATURE----- - 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 Mar 19 09:12:48 2003 Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h2JECmh23275 for ipseckey-outgoing; Wed, 19 Mar 2003 09:12:48 -0500 (EST) Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h2JECkK23270 for ; Wed, 19 Mar 2003 09:12:46 -0500 (EST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id CEF363F495; Wed, 19 Mar 2003 15:33:30 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003031915120818432 ; Wed, 19 Mar 2003 15:12:08 +0100 Received: from cthulhu.int-evry.fr (ivan.int-evry.fr [157.159.100.48]) by sparte.int-evry.fr (Postfix) with ESMTP id 518043F496; Wed, 19 Mar 2003 15:33:30 +0100 (CET) Received: from jjp by cthulhu.int-evry.fr with local (Exim 3.36 #1 (Debian)) id 18veIA-0000Af-00; Wed, 19 Mar 2003 15:11:42 +0100 Date: Wed, 19 Mar 2003 15:11:42 +0100 From: Jean-Jacques Puig To: Michael Richardson Cc: ipseckey Subject: Re: [IPSECKEY] misc Message-ID: <20030319141142.GA31724@ivan.int-evry.fr> References: <20030318111355.GA26577@ivan.int-evry.fr> <200303181908.h2IJ8k0q021556@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200303181908.h2IJ8k0q021556@marajade.sandelman.ottawa.on.ca> User-Agent: Mutt/1.5.3i Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca > Jean-Jacques> Is anyone aware of any informational documents or articles > Jean-Jacques> about considerations on the use of keys in the DNS system, > Jean-Jacques> from the point of view of > Jean-Jacques> replication/caching/revocation/propagation/... and some > > We have thought about it a lot, but I'm not sure what you are asking for. P. Hallam-Baker raised interesting points in his Dec.16 mail about DNS linked PKI. These sets some of the limits of what services linked to security we can expect DNS to provide. Publishing ipseckey rr, even with the use of DNSSEC will never end to favorize a kind of a world wide PKI scheme. These rr are interesting, though, even if key validation is not possible or if an offline scheme is needed. Ipseckey rr draft does not give recommendations about the use of such an rr (and it is not it's purpose anyway), and both DNS and corporate security may suffer from it's incorrect use. Thus, information is needed about the specificities of this system (because I believe it is more specific than common Directory/PKI schemes). A document should explain: - limits of PKI linking to DNS, with the scope / namezone of validation, the meaning of validation and of no-validation here. - key rr revocation pb, rr propagation, ... - the possible correlation between the lifetime of a record and the lifetime of a public key. - solving contradictions (where two DNS caches does not answer identic key rr for a same id. This may not be an issue, but some others may appear from replication and caching, and of course from corrupting players). - May dynamic dns, dns notify have consequences on the use of these rr ? - Stupid locks to avoid: getting the key of the dns through the dns in order to query the dns. This is not a problem when it is possible to revert to plain text, but this is a policy consideration all users of key rr may not have. May be there are other stupid locks for zone transfert, etc. I don't say that such a document should be provided by an international organisation or a wg. This may be the responsibility of a software manual. I only ask if such a document is available. May be there had been studies about some of the previous points with DNSSEC ? -- Jean-Jacques Puig - 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 Mar 19 13:26:02 2003 Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h2JIQ2408781 for ipseckey-outgoing; Wed, 19 Mar 2003 13:26:02 -0500 (EST) Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h2JIQ0108773 for ; Wed, 19 Mar 2003 13:26:00 -0500 (EST) Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54] (may be forged)) by peacock.verisign.com (8.12.8/) with ESMTP id h2JIPMwL028995; Wed, 19 Mar 2003 10:25:23 -0800 (PST) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Mar 2003 10:25:22 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: Jean-Jacques Puig , Michael Richardson Cc: ipseckey Subject: Beyond IPSECKEY RE: [IPSECKEY] misc Date: Wed, 19 Mar 2003 10:25:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca Abstract: The point of this note is to put forward some ideas for where I see IPSECKEY fitting into the overall scheme for widespread PKI deployment. I believe that what it is a first step on the way to something that is considerably more comprehensive, a generalized mechanism for advertising security policies through the DNS. > P. Hallam-Baker raised interesting points in his Dec.16 mail about DNS > linked PKI. These sets some of the limits of what services linked to > security we can expect DNS to provide. Publishing ipseckey > rr, even with > the use of DNSSEC will never end to favorize a kind of a > world wide PKI > scheme. These rr are interesting, though, even if key > validation is not > possible or if an offline scheme is needed. I believe that there is a need for two infrastructures, a naming infrastructure and a PKI infrastructure and that the PKI infrastructure should be linked to the naming infrastructure. In other words don't put *everything* into the DNS, management is going to be impossible. DNS is a management infrrastructure for domains and machines and NOT end users. But at the same time do not create a PKI that attempts to create an entirely parallel naming infrastructure as X.509 does. The primary key in a VeriSign SSL certificate is neither the Subject name or the issuer name, it is the DNS domain name. In other words the true structure is: DNS Name: AMAZON.COM Registered Office: 1 Book Warehouse Road, Seattle WA, USA Issuer: VeriSign Authentication Process: VTN Class 3. notBefore.. yadda yadda yadda... Same for an end entity certificate, the primary key is JeffB@amazon.com, his offline identity is actually irrelevant. Identity is a sufficient but not a necessary condition in most Internet security applications. To control risk it is not necessary to have identity unless I already have some relationship to a party and want to establish Correspondence between a network identity and an established offline identity. Control of risk in certain applications MAY require that I know that I can bind a network identity to an offline identity for the purpose of serving legal process. So lets get rid of the unhelpful and ambiguous concept of identity and instead consider the following issues: Correspondence of Network Address to Other Name Registered Office - Ability to serve Writ Authenticated Network Address The criteria that one needs to achieve varies considerably BY APPLICATION. Most E-Commerce applications require only the Registered Office level, some require the Correspondence level. For example the AuthentiCode deployment is intended to allow software downloads to be obtained with an equivalent level of security to obtaining software on CDROM in a shrinkwrap box. The requirement here is the registered office level of security. Thought for the day - what proportion of spam senders would find giving a registered office at which process could be served an impossible constraint on their business? OK so lets look at IPSECKEY, it is providing a key bound to a machine DNS address. The degree of operational security is not very high, the administrative process of installing the key does not provide for accountability and can thus be subverted with little effort, there is no safeguard if the machine the key is on becomes owned by an attacker. However the level of security required for the application in question is not high. All that is being asked for is a mechanism to turn on encryption. It is possible for a very sophisticated attacker to subvert the process with a man in the middle attack, however it is not possible to do this transparently. That is a major improvement in confidentiality. Knowing that I am being watched is in many cases more useful than keeping communications confidential. The primary benefit for IPSEC as far as I am concerned is the knowledge that the other side has a security capability. The actual key distribution is of secondary importance AFAIC, unauthenticated keys can be exchanged in band. Providing the key or a hash of the key in the DNS makes the attacker's job measurably harder, an additional platform must be compromised to compromise the system. it is a similar level of security to publishing hashes in the New York Times, it is a hard mechanism to subvert but not impossible. Security is risk control, not risk elimination. This type of mechanism raises the bar for attack significantly. If the application requires a higher degree of security it can be achieved by performing additional validation on the key by leveraging a PKI. So lets take the DNS security policy concept further. IPSEC key provides one mechanism for securing one protocol. It has the advantages of simplicity but will not serve for many important security questions, for example: * An Email does not have a digital signature, is it forged? * An SMTP response indicates that a server does not support TLS, is this true? What is needed here is a general and flexible mechanism for advertising security policy. i am currently working with some others on a draft called Security Policy Advertisement Mechanism that defines a generalized IPSECKEY type mechanism that allows end points to specify their security policy via the DNS. The basic model I take here is that the ability to configure the DNS records for a DNS zone constitutes ownership of a DNS name and that the owner of a DNS name has the right to establish security policies for all protocol uses in connection with that domain. So if I own hallambaker.com I have the right to say that all email from that zone MUST be signed under S/MIME using a key that is delegated from either a cert with hash X or a cert with hash Y (i.e. allowing for rollover). Clearly it is not a sensible idea to store end entity keys or certs in the DNS. The DNS is a per machine configuration mechanism and not a per user mechanism. The TTLs and whole operational setup of DNS are out of sync with those of managing end users. DNS is not designed as a PKI You can run an XKMS service on the same machine as a DNS server though. The Security Policy Advertisement Mechanism is similar to the existing SRV record approach in XKMS but takes the idea much further. The SRV approach is to access the DNS and get the director to the XKMS service. This has advantages when you are dealing with end users and in particular when you are do encryption in an asynchronous messaging context. SRV is less efficient when you are receiving messages and want to test for a downgrade attack on integrity. You don't know anything from the SRV record, you have to resolve it before you can even find out if there is a key and at the moment there is no policy associated with the key - it is just a key that you MAY use, nothing is said about whether the keyholder MUST use it. For example we might have a set of SPAM records that state that email from hallambaker.com ALWAYS comes from address X, Y or Z OPTIONAL uses STARTTLS, cert root has SHA1 P OPTIONAL uses S/MIME, cert root has SHA1 Q OPTIONAL uses PGP, validate against XKMS R NEVER uses NULL Authentication Phill - 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 Mar 19 16:54:55 2003 Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h2JLstl20753 for ipseckey-outgoing; Wed, 19 Mar 2003 16:54:55 -0500 (EST) 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 h2JLss120748 for ; Wed, 19 Mar 2003 16:54:54 -0500 (EST) Received: from sandelman.ottawa.on.ca ([66.114.232.119]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h2JLs0D15903 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Wed, 19 Mar 2003 16:54:21 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1] (may be forged)) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h2JLrvYH002596 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 19 Mar 2003 13:53:58 -0800 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-5) with ESMTP id h2JLrs9i002592; Wed, 19 Mar 2003 13:53:54 -0800 Message-Id: <200303192153.h2JLrs9i002592@marajade.sandelman.ottawa.on.ca> To: ipseckey cc: Jean-Jacques Puig Subject: Re: [IPSECKEY] misc In-reply-to: Your message of "Wed, 19 Mar 2003 15:11:42 +0100." <20030319141142.GA31724@ivan.int-evry.fr> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 19 Mar 2003 13:53:53 -0800 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jean-Jacques" == Jean-Jacques Puig writes: Jean-Jacques> Is anyone aware of any informational documents or articles Jean-Jacques> about considerations on the use of keys in the DNS system, Jean-Jacques> from the point of view of Jean-Jacques> replication/caching/revocation/propagation/... and some >> >> We have thought about it a lot, but I'm not sure what you are asking for. Jean-Jacques> Ipseckey rr draft does not give recommendations about the Jean-Jacques> use of such an rr (and it is not it's purpose anyway), and Jean-Jacques> both DNS and corporate Is it that you are looking for a document that might be entitled: "Operational considerations and limitations of IPSECKEY RR" ? ] ON HUMILITY: to err is human. To moo, bovine. | 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 Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPnjm8IqHRg3pndX9AQGHFwQAzugKe1BLeedXzS74YE+8/pUwu4jKHSaA 2flHxlQjfl1n05yTGZpEdfdnr5cf84ODUngXUna7bXdprWWPfq46OhJgTkhwFyUu ohAX0iL1GqSudw/xL9NATo+prJkgcVORlwb4ilP3Axtb28vFs6bwnpVOFFkQ/dnF bUv9bgaRmUE= =nqzW -----END PGP SIGNATURE----- - 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 Thu Mar 20 00:57:14 2003 Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h2K5vEQ19231 for ipseckey-outgoing; Thu, 20 Mar 2003 00:57:14 -0500 (EST) 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 h2K5vCI19217 for ; Thu, 20 Mar 2003 00:57:13 -0500 (EST) Received: from sandelman.ottawa.on.ca ([66.114.232.119]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h2K5uDD17870 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Thu, 20 Mar 2003 00:56:40 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1] (may be forged)) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h2K5uAYH013104 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 19 Mar 2003 21:56:11 -0800 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-5) with ESMTP id h2K5u7Wo013101 for ; Wed, 19 Mar 2003 21:56:09 -0800 Message-Id: <200303200556.h2K5u7Wo013101@marajade.sandelman.ottawa.on.ca> To: ipseckey Subject: [IPSECKEY] new revision of draft Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 19 Mar 2003 21:56:06 -0800 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca http://www.sandelman.ca/SSW/ietf/ipsec/key/draft-ipseckey-rr-00b.txt will go to the ID editor next week, unless I find time to revise it again before then. ] ON HUMILITY: to err is human. To moo, bovine. | 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 Debian GNU/Linux using, kernel hacking, security guy"); [ - 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 Thu Mar 20 03:57:13 2003 Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h2K8vDx11837 for ipseckey-outgoing; Thu, 20 Mar 2003 03:57:13 -0500 (EST) Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h2K8vAI11824 for ; Thu, 20 Mar 2003 03:57:10 -0500 (EST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 0C1983F42C; Thu, 20 Mar 2003 10:18:09 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003032009562931423 ; Thu, 20 Mar 2003 09:56:29 +0100 Received: from cthulhu.int-evry.fr (ivan.int-evry.fr [157.159.100.48]) by sparte.int-evry.fr (Postfix) with ESMTP id 5C5DB3F42C; Thu, 20 Mar 2003 10:18:08 +0100 (CET) Received: from jjp by cthulhu.int-evry.fr with local (Exim 3.36 #1 (Debian)) id 18vvpn-0001HB-00; Thu, 20 Mar 2003 09:55:35 +0100 Date: Thu, 20 Mar 2003 09:55:30 +0100 From: Jean-Jacques Puig To: Michael Richardson Cc: ipseckey , Jean-Jacques Puig Subject: Re: [IPSECKEY] misc Message-ID: <20030320085530.GB4765@ivan.int-evry.fr> References: <20030319141142.GA31724@ivan.int-evry.fr> <200303192153.h2JLrs9i002592@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200303192153.h2JLrs9i002592@marajade.sandelman.ottawa.on.ca> User-Agent: Mutt/1.5.3i Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca On Wed, Mar 19, 2003 at 01:53:53PM -0800, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "Jean-Jacques" == Jean-Jacques Puig writes: > Jean-Jacques> Is anyone aware of any informational documents or articles > Jean-Jacques> about considerations on the use of keys in the DNS system, > Jean-Jacques> from the point of view of > Jean-Jacques> replication/caching/revocation/propagation/... and some > >> > >> We have thought about it a lot, but I'm not sure what you are asking for. > > Jean-Jacques> Ipseckey rr draft does not give recommendations about the > Jean-Jacques> use of such an rr (and it is not it's purpose anyway), and > Jean-Jacques> both DNS and corporate > > Is it that you are looking for a document that might be entitled: > "Operational considerations and limitations of IPSECKEY RR" > ? Yes, exactly. Though some points may apply to DNS KEY RR too. -- Jean-Jacques > > ] ON HUMILITY: to err is human. To moo, bovine. | 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 Debian GNU/Linux using, kernel hacking, security guy"); [ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.7 (GNU/Linux) > Comment: Finger me for keys > > iQCVAwUBPnjm8IqHRg3pndX9AQGHFwQAzugKe1BLeedXzS74YE+8/pUwu4jKHSaA > 2flHxlQjfl1n05yTGZpEdfdnr5cf84ODUngXUna7bXdprWWPfq46OhJgTkhwFyUu > ohAX0iL1GqSudw/xL9NATo+prJkgcVORlwb4ilP3Axtb28vFs6bwnpVOFFkQ/dnF > bUv9bgaRmUE= > =nqzW > -----END PGP SIGNATURE----- - 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 Thu Mar 20 03:58:21 2003 Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h2K8wLr12171 for ipseckey-outgoing; Thu, 20 Mar 2003 03:58:21 -0500 (EST) Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h2K8wJI12159 for ; Thu, 20 Mar 2003 03:58:19 -0500 (EST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id AA3B83F4C2; Thu, 20 Mar 2003 10:19:20 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003032009574005405 ; Thu, 20 Mar 2003 09:57:40 +0100 Received: from cthulhu.int-evry.fr (ivan.int-evry.fr [157.159.100.48]) by sparte.int-evry.fr (Postfix) with ESMTP id E9CA73F4C2; Thu, 20 Mar 2003 10:19:19 +0100 (CET) Received: from jjp by cthulhu.int-evry.fr with local (Exim 3.36 #1 (Debian)) id 18vvqx-0001HW-00; Thu, 20 Mar 2003 09:56:47 +0100 Date: Thu, 20 Mar 2003 09:56:42 +0100 From: Jean-Jacques Puig To: Sam Weiler Cc: Jean-Jacques Puig , ipseckey Subject: Re: [IPSECKEY] misc Message-ID: <20030320085642.GC4765@ivan.int-evry.fr> References: <20030318111355.GA26577@ivan.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca On Wed, Mar 19, 2003 at 02:24:55PM -0500, Sam Weiler wrote: > On Tue, 18 Mar 2003, Jean-Jacques Puig wrote: > > > It seems (to me) that the draft has reached a certain maturity. > > Being far from SF (and also timezonely phased out), I would be very > > pleased if someone could gave to the list a feedback about today's > > session (I mean, before a ``minutes'' digest if any :-). > > As requested, summary points from yesterday's meeting: > > Micheal's draft was accepted as a WG work item. > > No other proposals were presented. > > It seems likely that the draft will go to WG Last Call as soon as a > new version is published, which should happen as soon as the i-d > editor queue opens back up. This would be an excellent time to read the > draft with a fine toothed comb or to contribute text (especially for the > introduction). Perhaps Micheal will post the current working version? > > If anyone objects to this document being accepted, speak up. If anyone > has a better proposal, speak up. > > -- Sam Thanks for the summary :-) ! -- Jean-Jacques - 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 Thu Mar 20 08:40:35 2003 Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h2KDeZ417581 for ipseckey-outgoing; Thu, 20 Mar 2003 08:40:35 -0500 (EST) Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h2KDeYI17573 for ; Thu, 20 Mar 2003 08:40:34 -0500 (EST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 233033F427; Thu, 20 Mar 2003 15:01:39 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003032014395504293 ; Thu, 20 Mar 2003 14:39:55 +0100 Received: from cthulhu.int-evry.fr (ivan.int-evry.fr [157.159.100.48]) by sparte.int-evry.fr (Postfix) with ESMTP id 9B6AF3F427; Thu, 20 Mar 2003 15:01:38 +0100 (CET) Received: from jjp by cthulhu.int-evry.fr with local (Exim 3.36 #1 (Debian)) id 18w0GU-0001c5-00; Thu, 20 Mar 2003 14:39:26 +0100 Date: Thu, 20 Mar 2003 14:39:26 +0100 From: Jean-Jacques Puig To: Michael Richardson Cc: ipseckey Subject: Re: [IPSECKEY] new revision of draft Message-ID: <20030320133926.GA6052@ivan.int-evry.fr> References: <200303200556.h2K5u7Wo013101@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200303200556.h2K5u7Wo013101@marajade.sandelman.ottawa.on.ca> User-Agent: Mutt/1.5.3i Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca Hello, Some remarks about the draft: >1.1 Overview > > The IPSECKEY resource record (RR) is used to publish a public key > that is to be associated with a Domain Name System (DNS) name. It > will be a public key as only public keys are stored in the DNS. This > can be the public key of a host, network, or application (in the case > of per-port keying). Can you be more accurate about public key for an application and pert-port keying ? >2.2 RDATA format - algorithm type > > The algorithm type field indicates the type of key that is present in > the public key field. A positive number, larger than 0 identifies an > algorithm type. The values are the same as those defined for DNS > Security Algorithm Numbers ([6]). > > A value of 0 indicates that no key is present. > > The following values defined by IANA are useful: > > 3 A DSA key is present, in the format defined in [7] > > 5 A RSA key is present, in the format defined in [8] >2.4 RDATA format - RSA public key > > If the algorithm type has the value 1, then public key portion ^ 5 ? >2.5 RDATA format - DSA public key > > If the algorithm type has the value 2, then public key portion ^ 3 ? >3.1 Representation of IPSECKEY RRs > > IPSECKEY RRs may appear as lines in a zone data master file. The > precedence, algorithm and gateway fields are mandatory. There base64 > encoded public key block is optional. > If no gateway is to be indicated, then the root (".") should be used. Sorry, I am a bit lost here. Do you mean a gateway *field* is REQUIRED, though a gateway address is optional (according to section 2.1) ? Also section 2.1 does not state public key is optional. May be section 2.1 should say something like 'gateway is mandatory but can be self "(.)", and key is mandatory in the case gateway is self and optional in the other cases' ? -- Jean-Jacques - 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 Thu Mar 20 13:54:05 2003 Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h2KIs5M06063 for ipseckey-outgoing; Thu, 20 Mar 2003 13:54:05 -0500 (EST) 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 h2KIs4n06058 for ; Thu, 20 Mar 2003 13:54:04 -0500 (EST) Received: from sandelman.ottawa.on.ca ([66.114.232.119]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h2KIrAD19755 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Thu, 20 Mar 2003 13:53:31 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1] (may be forged)) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h2KIr8YH030468 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 20 Mar 2003 10:53:08 -0800 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-5) with ESMTP id h2KIr6pV030465 for ; Thu, 20 Mar 2003 10:53:07 -0800 Message-Id: <200303201853.h2KIr6pV030465@marajade.sandelman.ottawa.on.ca> To: ipseckey@sandelman.ca Subject: Sam Weiler: Re: [IPSECKEY] misc Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 20 Mar 2003 10:53:05 -0800 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca (Adding weiler@watson.org to -nomail list. Likely, unless someone objects, I will move the list from a very old majordomo1 install, to a MJ2 install next week, or perhaps earlier) From: Sam Weiler Reply-To: Sam Weiler To: Jean-Jacques Puig cc: ipseckey Subject: Re: [IPSECKEY] misc In-Reply-To: <20030318111355.GA26577@ivan.int-evry.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 18 Mar 2003, Jean-Jacques Puig wrote: > It seems (to me) that the draft has reached a certain maturity. > Being far from SF (and also timezonely phased out), I would be very > pleased if someone could gave to the list a feedback about today's > session (I mean, before a ``minutes'' digest if any :-). As requested, summary points from yesterday's meeting: Micheal's draft was accepted as a WG work item. No other proposals were presented. It seems likely that the draft will go to WG Last Call as soon as a new version is published, which should happen as soon as the i-d editor queue opens back up. This would be an excellent time to read the draft with a fine toothed comb or to contribute text (especially for the introduction). Perhaps Micheal will post the current working version? If anyone objects to this document being accepted, speak up. If anyone has a better proposal, speak up. -- Sam - 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 Sat Mar 22 23:38:12 2003 Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h2N4cCn06979 for ipseckey-outgoing; Sat, 22 Mar 2003 23:38:12 -0500 (EST) Received: from one.elistx.com (one.elistx.com [209.116.252.130]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h2N4cAG06949 for ; Sat, 22 Mar 2003 23:38:10 -0500 (EST) Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HC60059YQ840C@eListX.com> for ipseckey@lox.sandelman.ottawa.on.ca; Sat, 22 Mar 2003 23:38:29 -0500 (EST) Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h2N4cMj4009793; Sat, 22 Mar 2003 23:38:27 -0500 (EST envelope-from ogud@ogud.com) Date: Sat, 22 Mar 2003 23:36:07 -0500 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: [IPSECKEY] new revision of draft In-reply-to: <200303200556.h2K5u7Wo013101@marajade.sandelman.ottawa.on.c a> X-Sender: post@localhost To: Michael Richardson , ipseckey Message-id: <5.1.1.6.2.20030322232041.01a8b5b8@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca At 00:56 2003-03-20, Michael Richardson wrote: >http://www.sandelman.ca/SSW/ietf/ipsec/key/draft-ipseckey-rr-00b.txt >will go to the ID editor next week, unless I find time to revise it >again before then. Please read ID-nits before submitting this one http://www.ietf.org/ID-nits.html Abstract contains a Reference (not allowed makes it hard to read in isolation (say in the announcement). Overview, paragraph 2. s/by a SIG resource record/by DNSSEC/ Overview paragraph 4. class independent ??? Ipsec is only defined for IP protocol that uses A and AAAA records that are only in IN class. Section 2 needs reordering Explain fields in the same order as they appear in the Resource record, currently they are out of order as they used to be in an old version of the record. In short 2.3 --> 2.2 2.2 --> 2.3 2.6 --> 2.4 2.4 --> 2.5 but this repeats text from 2535 replace with a reference to the exact section in 2535. 2.5 --> 2.5 this is only a reference so keep it as is. Section 3. All the example IPSECKEY's have algorithm #1 s/1/5/ Section 3.1 s/should/SHOULD/ References RFC 103[45] are normative as well as 253[56] and 3110 others are informational. Olafur - 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 Tue Mar 25 11:22:40 2003 Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h2PGMe725882 for ipseckey-outgoing; Tue, 25 Mar 2003 11:22:40 -0500 (EST) 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 h2PGMbq25876 for ; Tue, 25 Mar 2003 11:22:37 -0500 (EST) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.8/8.12.8) with ESMTP id h2PGLtjJ087843 for ; Tue, 25 Mar 2003 11:21:56 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.12.8/8.12.8/Submit) with SMTP id h2PGLtFO087838 for ; Tue, 25 Mar 2003 11:21:55 -0500 (EST) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 25 Mar 2003 11:21:54 -0500 (EST) From: Sam Weiler To: ipseckey Subject: Re: [IPSECKEY] new revision of draft Message-ID: 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 Bunches of editorial suggestions... -- Sam Abstract: ...describes the IPSECKEY resource... and nuke the reference, as someone else noted. I suggest striking: "It will be a public key as only public keys are stored in the DNS." Section 1.1: It is expected that there will often be multiple resource records of the IPSECKEY type. This will be due to the need to rollover keys, and due to the presence of multiple gateways. There will often be multiple IPSECKEY resource records (add: at the same name?), due to the presence of multiple gateways and the need to rollover keys. Section 2.2: Section 2.3: change to "in the same was as" or describe the exact interpretation -- the current wording is vague. Section 2.4: Needs to have generic text for any value, then the expansion for RSA and maybe mention the DSA doc, but not in it's own subsection. Section 2.6: The first paragraph isn't a clear as I'd like to see it, but I don't have suggested text. wire-encoded ^ Drop the self-describing length mention (not necessary, since it's in the reference). Rather than "most commonly", describe WHY it should be that. 3.1 s/there/the/ s/should/???/ SHOULD? MUST? 3.2 Make the lead-in text into correct sentences. I'd omit the full length key -- use a short key for demonstration, or abbreviate it somehow. 4 drop the 43 reference, presumably? "public" algorithm field, huh? - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed.