To:
Jakob Schlyter <jakob@crt.se>, Olafur Gudmundsson <ogud@ogud.com>
Cc:
<dnssec@cafax.se>, <sra@hactrn.net>
From:
Olafur Gudmundsson <ogud@ogud.com>
Date:
Wed, 25 Apr 2001 10:37:12 -0400
Delivery-Date:
Thu Apr 26 08:16:19 2001
In-Reply-To:
<Pine.BSO.4.33.0104202353040.24513-100000@fonbella.crt.se>
Sender:
owner-dnssec@cafax.se
Subject:
Re: Keys at apex problem - New PUBKEY RR?
At 18:14 20-04-2001, Jakob Schlyter wrote:
>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?
Good,
> > 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?
anything that potentially overflows a packet size is a problem,
depending on how many keys you need to overflow dictates if the problem is
small or big :-.
> > 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?
possible but this is the cleanest solution it is up to the working group
to decide if this is the right way to go forward.
> > 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
in this case the regular KEY record is used.
The open question is who gets to pick the name, working groups or IANA?
Olafur