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


To: <dnssec@cafax.se>
From: "Scott Rose" <scottr@antd.nist.gov>
Date: Tue, 4 Sep 2001 14:24:12 -0400
Sender: owner-dnssec@cafax.se
Subject: Re: CERTificates and public keys

I haven't heard much support of the RFC 2535 version of using KEY records
for non-DNSSEC key storage, and I have no problems with restricting the KEY
record to be used solely for DNS keys.

So either store non-DNS keys in a new record, or use the CERT record.
Either solution is (splitting hairs) a non-DNSSEC issue, but a "using DNS in
support of other protocols" issue.  In this case, another protocol using
DNSSEC to provide some security features.

The downside of creating a new "raw key" type for the CERT record is that
there is no protocol field in the record to indicate the protocol for the
key stored in the record.  There are only 3 fields:  type, key tag, and
algorithm.  However, the "type" field is 16 bits (compared to the KEY
record's 8 bits), so there are more codes available

So the questions are:
1.  KEY for DNSSEC use primarily (SHOULD or MUST if we want to be strict.).
2.  Non-dnssec keys:  CERT or new record?

Issue 1 is a DNSSEC protocol issue, 2 isn't, but may rely on DNSSEC being
deployed
Scott


----- Original Message -----
From: "Dan Massey" <masseyd@isi.edu>
To: "Jakob Schlyter" <jakob@crt.se>
Cc: "Derek Atkins" <warlord@MIT.EDU>; "Scott Rose" <scottr@antd.nist.gov>;
<dnssec@cafax.se>
Sent: Tuesday, September 04, 2001 1:57 PM
Subject: Re: CERTificates and public keys


> On Tuesday, September 04, 2001 at 07:23PM, Jakob Schlyter wrote:
> | On 4 Sep 2001, Derek Atkins wrote:
> |
> | > It's well known that 2535 needs updating.  We don't need APPKEY
> | > to do it.
> |
> | if we choose not to store raw public keys in CERT, we need something
like
> | APPKEY.
> |
> | I'm not sure how we can move forward on this discussion - we either have
> | people who think it's misuse to put raw public keys in CERT and people
who
> | doesn't think there is a problem with doing that. the former probably
> | support APPKEY and the latter does not.
> |
> | jakob
>
> Perhaps we have some consensus on at least one point.  Does anyone object
> to restricting the KEY so it only holds DNS keys?
>
> Application keys will be stored in some form of APPKEY or CERT, but we
> clearly don't agree on the details yet.  If there is some consensus on
> restricting the KEY RR, this would greatly help Scott and I in the RFC
> 2535 update.
>
> Dan


Home | Date list | Subject list