Re: Keys at apex problem - New PUBKEY RR?

[Olafur Gudmundsson <ogud@ogud.com>]

At 11:29 26-04-2001, Havard Eidnes wrote:
> > > > >$origin east.isi.edu.
> > > > >@               IN      SOA     ...
> > > > >@                       NS      ...
> > > > >@                       A       38.245.76.2
> > > > >@                       KEY     <zone key>
> > > > >_ssh._tcp               SRV     0 0 @
> > > > >_ssh._tcp               KEY     <ssh host key material>
> > > >
> >
> > In this case the SRV record is redundant.
>
>Uhm, excuse me?  It serves to move the SSH application KEY record
>away from the zone apex, which was otherwise the major sticking
>point with the original proposal, if I recall correctly?

Ok, let me be pedantic in this message.
Problem 1.
Certain zone had multiple services at one name few of them requiring/wanting
KEY records at the top, resulting in a large keyset requiring TCP to get
all the records.

Problem 2. (Also by Dan I think )
Are parents willing to sign key sets for children with NON ZONE keys in them ?

Problem 3.
How to break key sets into smaller sets, to avoid having resolver search
through large key sets to find one particular key.


Goal 1.
Make finding protocol specific keys as simple as possible.

Goal 2. (not all solutions meet this one)
Minimize search by resolvers in returned key sets.

SRV was mentioned as a possible solution.

SRV defines a predicable mechanism to find where a particular service
for a name is located and if there are multiple sources how to select
among them.

Another solution mentioned was to store SSH keys at a predicable prefix
of a name.
Someone mentioned that reusing the SRV name space was a possibility.

We do not want to reinvent the wheel many times, thus my suggestion reuse
SRV name space without the SRV record WHEN there is no redirection.
Thus my comments about the SRV record being redundant.
IF there is a redirection then we MUST use SRV record(s).

Now the question that I forgot all about until reading this message,
thanks for bringing it to my attention.

If there is a redirection in what cases MUST the key be stored with
the SRV record versus the target.
Example: (ssh is not the best protocol for this example but will do).
_ssh._tcp.example.com.  SRV     0 0 22022 terminal.example.com.
and later in the zone there is
_ssh._tcp.HOST.example.com.     SRV     0 0 22122 terminal.example.com

In this case does terminal use one or two different host keys ?
If the answer is one then the key should be stored with at
         _ssh._tcp.terminal.example.com.
on the other hand if the keys are different then I can make an argument
for storing the keys with the SRV record rather than have one large KEY
set at terminal.

         Olafur