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