To:
Scott Rose <scottr@antd.nist.gov>
Cc:
Miek Gieben <miekg@nlnetlabs.nl>, dnssec@cafax.se
From:
Dan Massey <masseyd@isi.edu>
Date:
Thu, 19 Apr 2001 10:03:08 -0400
Content-Disposition:
inline
Delivery-Date:
Thu Apr 19 20:31:05 2001
In-Reply-To:
<006601c0c8d6$243b5a80$b9370681@antd.nist.gov>; from scottr@antd.nist.gov on Thu, Apr 19, 2001 at 09:39:21AM -0400
Sender:
owner-dnssec@cafax.se
User-Agent:
Mutt/1.2.5i
Subject:
Re: Keys at apex problem - New PUBKEY RR?
On Thursday, April 19, 2001 at 09:39AM, Scott Rose wrote: | | ----- Original Message ----- | From: "Miek Gieben" <miekg@nlnetlabs.nl> | To: "Scott Rose" <scottr@antd.nist.gov> | Cc: <dnssec@cafax.se> | Sent: Thursday, April 19, 2001 9:33 AM | Subject: Re: Keys at apex problem - New PUBKEY RR? | | | > On Thu, Apr 19, 2001 at 09:06:48AM -0400, Scott Rose wrote: | > > A PUBKEY RR would look like the KEY RR now: with a protocol and | algorihtm | > > field, but the flags would not be needed (or reduced). I would assume | the | > > protocol using DNS to search for a public key would know how to | interpret it | > > in the reply. The PUBKEY RR would be like the CERT RR now - separate | from | > > DNSSEC. It could even be used without DNSSEC (I know, it wouldn't be | smart | > > to accept a key without a verified SIG). | > why not used CERT then? | > | > it looks to me if we're re-doing CERT records? | > | > grtz Miek | | | 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. Dan