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


To: Olafur Gudmundsson <ogud@ogud.com>
Cc: Dan Massey <masseyd@isi.edu>, <dnssec@cafax.se>, <sra@hactrn.net>
From: Jakob Schlyter <jakob@crt.se>
Date: Sat, 21 Apr 2001 00:14:43 +0200 (CEST)
Delivery-Date: Sat Apr 21 15:24:40 2001
In-Reply-To: <5.0.2.1.0.20010420165942.00ab19b0@localhost>
Sender: owner-dnssec@cafax.se
Subject: Re: Keys at apex problem - New PUBKEY RR?

On Fri, 20 Apr 2001, Olafur Gudmundsson wrote:

> I think we should pick one of 1, 2 or 3 and suggest that in an ID as soon as
> possible.

I would be interested in working on a ID describing this, but I need
assistance. Dan?

> Solution 1 (KEY + APPKEY) has the lowest cost,
> cost:   same number of names
>          one more type regardless of number of application keys
>          one more signature
> drawbacks:  many security aware applications will cause large key sets.
>          if applications want to define use of flags we may run out of flags
>          or overload flags between applications.
> advantages: simple to deploy one time cost.

should we consider the risk of large key sets a big problem?

> Solution 2 KEY + <app>key type
> cost:   same number of names
>          one type for each application supported by name
>          more types to sign
> drawbacks: DNS servers and resolver must support unknown types for rapid
>          deployment of new application key types.
> advantages: small key sets that are easy to find no searching in key list
>          Each type has clean slate on use of flags and does not affect any
>          other applications.

are the drawbacks perhaps so large that people will not use this for
applications?

> Solution 3: KEY and _<app>.name KEY
> cost:   extra name for every application
>          extra NXT/NO set
>          2 more signatures per key set.
> drawbacks: same as 1. + the extra set
> advantages: small keys sets (just like 2).

I like this more and more. perhaps more realistic that 1. _app should be
defined in a document per application, but that is needed anyway to
describe the RDATA format


/Jakob

--
Jakob Schlyter <jakob@crt.se>                Network Analyst
Phone:  +46 31 701 42 13, +46 70 595 07 94   Carlstedt Research & Technology





Home | Date list | Subject list