Subject: RE: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt

From: "Loomis, Rip" <[email-masked]>
Date: Fri, 12 Jul 2002 10:16:02 -0400

> > > "Is restricting the use of the KEY RR a good idea".
> >
> > Yes.  Has anyone been arguing that it isn't?
>
> That opinion has been expressed to me in private e-mails and
> in person at the last IETF.
> 
> There is a feeling of betrayal by some people that looked to
> DNSSEC as a ready made PKI that was just around the corner
> has been taken away.

But this isn't the "Internet Try-not-to-make-anyone-feel-betrayed
Task Force".  If we could find the ITTF, maybe those folks would
try to help us.

In the meantime, we're engineering.  Having KEY records available
for uses other than DNSSEC keys *might* have been at least an Okay
Thing.  Therefore, that was the way things were originally written.
However, experience shows that trying to deal with a load of extra
KEY records in the middle of each DNSSEC validation turns out to be
a Bad Thing.  We must therefore revert to being part of the I _E_ TF,
and update the RFCs appropriately.

The no-brainer way (IMHO) to engineer a solution that allows DNSSEC to
function is to restrict KEY for DNSSEC.  In fact, I haven't seen
any discussion of any other reasonable solution--and I am still going
on the basis that DNSSEC remains on the standards track and therefore
should be supported appropriately.

There was previous discussion of APPKEY and/or CERT records,
and I'm not quite sure how we (now) seem to have lost the previous
consensus.  For right now, though, I would ask that anyone who
can't live with the restrict-KEY draft *please* clearly state
your objections--once that's out of the way *then* we can address
APPKEY/CERT/SINK/whatever and engineer an appropriate solution.

Or am I missing something?

  --Rip

--
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/>