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