To:
Dan Massey <masseyd@isi.edu>
Cc:
Scott Rose <scottr@antd.nist.gov>, Miek Gieben <miekg@nlnetlabs.nl>, <dnssec@cafax.se>
From:
Jakob Schlyter <jakob@crt.se>
Date:
Thu, 19 Apr 2001 16:36:07 +0200 (CEST)
Delivery-Date:
Thu Apr 19 20:31:11 2001
In-Reply-To:
<20010419100308.B3247@snarl.east.isi.edu>
Sender:
owner-dnssec@cafax.se
Subject:
Re: Keys at apex problem - New PUBKEY RR?
On Thu, 19 Apr 2001, Dan Massey wrote: > | Yup, it does, maybe more advertising of CERT is in order (and guidelines for > | using it to encode public keys). We could still make the KEY RR a > | "dnssec-only" record, and force the issue by making the changes I mentioned. > | > | Scott > | > > This sounds very good to me... it seems like it would not be very > disruptive to DNSSEC and would move the keys at apex problem out of > the way. I don't agree. the source of this problem is the parent's SIG of the childs KEY, right? in DNSSEC today, this SIG covers all KEYs of the apex and that's why we don't want to have application KEYs at the apex (and only at the apex, other places in the tree is not a problem). KEY was designed to carry keys - both DNSSEC infrastructual keys and applications keys. CERT was designed to carry certificates, i.e. keys with signature and some other data. don't mix these two. could this be solved in another way? remove the KEY at apex problem by not using SIG(KEY()) at the apex in the parent, i.e. another way of the parent signing the child? a separate RR? /Jakob -- Jakob Schlyter <jakob@crt.se> Network Analyst Phone: +46 31 701 42 13, +46 70 595 07 94 Carlstedt Research & Technology