To:
"Miek Gieben" <miekg@nlnetlabs.nl>
Cc:
<dnssec@cafax.se>
From:
"Scott Rose" <scottr@antd.nist.gov>
Date:
Thu, 19 Apr 2001 09:39:21 -0400
Delivery-Date:
Thu Apr 19 20:31:02 2001
Sender:
owner-dnssec@cafax.se
Subject:
Re: Keys at apex problem - New PUBKEY RR?
----- 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