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


To: "Jakob Schlyter" <jakob@crt.se>, "Dan Massey" <masseyd@isi.edu>
Cc: <dnssec@cafax.se>
From: "Scott Rose" <scottr@antd.nist.gov>
Date: Wed, 18 Apr 2001 09:52:21 -0400
Delivery-Date: Thu Apr 19 06:43:21 2001
Sender: owner-dnssec@cafax.se
Subject: Re: Keys at apex problem




> On Wed, 18 Apr 2001, Dan Massey wrote:
>
> > Do I tell the administrator to:
> >
> > 1) Ignore the SHOULD and put the ssh key at the apex anyway.
> >        The isi.edu zone will have to store the ssh key
> >        and east.isi.edu must involve the parent in any ssh key change.
> >        The ssh client should accept the ssh key for east.isi.edu based
on
> >          the SIG from the isi.edu zone key?? (stored at isi.edu)
> >          the SIG from the east.isi.edu key?? (stored at easti.isi.edu)
> >          either SIG??
> >          both SIGs??
>
> what if on of the SIGs, if there is two, fails to verify? is it broken?

Depending on how RFC2535 was interpreted by the resolver implementer ;-)

If the resolver believes east.isi.edu to be owned by the isi.edu zone, the
isi.edu SIG will be trusted over one from east.isi.edu, even if east.isi.edu
really is the authority of the east hostname because [isi.edu <
east.isi.edu]

> > 3) The SSH keys shouldn't be present in the zone file.
> >        Replace SSH with IPSEC, SSL, etc, etc and you have the same
problem.
> >        If the KEY record is only for zone keys, let's make the spec say
that.
>
> we could of course define a new CERT format for use with SSH, but I'm not
> sure that would give more gain that pain (even though there are SSH
> implementations that supports X.509-based authentication).
>

Is this another "vote" in favor of a new RR for non-DNSSEC public keys?
This would give the appearance of being cleaner:  i.e.  have a a PUBKEY RR
for all other protocols, but we still have the problem of which zone has
signing authority for name.

> > Currently I'm using option 4 which is to avoid the east.isi.edu zone
> > administrator. :)
>
> or perhaps,
>
> 5) don't add a KEY for the host with the same name as the zone. the
> host is probably reachable by some other name that people should
> use instead. A records at the apex is only use for web anyway.
>

Probably the best work-around, but really couldn't be made part of a
protocol standard.  Best Common Practice perhaps.

Scott

===============================================================
Scott Rose
Advanced Network Technologies Division
NIST

ph: 301-975-8439                       fax: 301-590-0932
http://www.nist.gov
===============================================================


Home | Date list | Subject list