Subject: draft-richardson-ipsec-rr-00.txt

From: Michael Richardson <[email-masked]>
Date: Wed, 04 Sep 2002 18:20:24 -0400

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

-----BEGIN PGP SIGNED MESSAGE-----

I have seen no discussion about my proposal. I will assume that it was
well taken. 

I would ask that the WG consider adopting proposal for incorporation into the
new set of DNSSEC documents that are being prepared. 

====

I would very much like to make sure that restrict-key-for-dnssec properly
documents the arguments, so that they don't need to repeated endlessly.

This means detailing the following things:

1) "problematic" (I would write text, but I don't know what the problems are).

2) Detail, with an example, how additional KEY RR at the APEX of a zone 
   cause problems for resolvers. 

3) explain how public keys and IP addresses are different. Explain
   how it is that we are willing to sign A records, even though it is
   often the case that one is managed by network admins, while the other is
   managed by DNS admins.

4) how the solution of moving non-DNSSEC keys to another RR deals with
   the motivations 2,3,5,6. It seems that the presence of any non-DNSSEC
   key could "confuse" someone.

5) explain the impact of DS on the concerns about exchange of public
   key info with the parent.

6) explain why rules concerning placement of non-DNSSEC KEY RR will not
   solve the described problems.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>