[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Jakob Schlyter <jakob@crt.se>
Cc: Scott Rose <scottr@antd.nist.gov>, Miek Gieben <miekg@nlnetlabs.nl>, dnssec@cafax.se
From: Dan Massey <masseyd@isi.edu>
Date: Thu, 19 Apr 2001 17:06:56 -0400
Content-Disposition: inline
Delivery-Date: Fri Apr 20 07:49:39 2001
In-Reply-To: <Pine.BSO.4.33.0104191612420.6456-100000@fonbella.crt.se>; from jakob@crt.se on Thu, Apr 19, 2001 at 04:36:07PM +0200
Sender: owner-dnssec@cafax.se
User-Agent: Mutt/1.2.5i
Subject: Re: Keys at apex problem - New PUBKEY RR?

Based on the discussion and attempts to make the ssh keys work, 
I'm convinced of the following: 

DNSSEC infrastructure keys have special signing rules that involve 
the parent zone.  Maintaining these keys requires cooperation between
the zone and its parent.  Resolvers must use these keys during
the DNS authentication process and typically don't pass these keys
back to the end applications.  

Application keys should not have any special signing rules and should
be signed by the zone that owns them.  Maintaining these keys is 
something that should be done by the individual zone.  Resolvers must 
not use these keys during the DNS authentication process and should 
treat these keys like any other data that is passed back to some end 
application.

Combining these two different things into one KEY record creates 
problems.  Putting an application KEY at the apex illustrates the 
differences and results in problems for zone signing, zone 
administration, and leads to complicated/confusing rules for 
resolvers.  

There is serious concern about redesigning or delaying DNSSEC,  
but I think we can avoid major problems here.  Keep the KEY record 
format as it is,  only restrict the protocol types so only DNSSEC 
infrastructure keys are allowed (i.e. drop email and ipsec from 2535).  
Technically bind9 would not be compliant with this new spec because 
it would let you load a KEY with the (no longer valid) IPSEC type into 
your zone (even at the apex!)  However, adjusting the next version of 
BIND or patching the old version should be fairly simple.  Also, you
can run the existing BIND, don't enter KEY records with the invalid
type into your zone file and complain to any zone that does this
and pollutes your cache.  

There are very few, if any, fully developed and widely deployed 
applications that rely on the application KEY record.   These few 
applications will have to change.  The open question is change to 
what...  One option is to use the CERT record.  Another option is 
create a new PUBKEY record for application keys.   I think the 
infrastructure KEY is fundamentally different than the CERT and 
PUBKEY records because of the way KEYs are signed, authenticated, 
and used.  I don't know if CERT should be used for general public 
keys or if having both CERT and PUBKEY would be duplication.  However, 
CERT/PUBKEY belong in their own documents. 

So I guess that is the very long way of saying I'm in favor of
separating DNS infrastructure keys from application keys. I think
either CERT only or CERT+PUBKEY would work, but I don't know which 
of those two is better.

Dan

Home | Date list | Subject list