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


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


Home | Date list | Subject list