Re: Keys at apex problem

[Jakob Schlyter <jakob@crt.se>]

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?

> 2) The A record is no longer allowed at the apex
>        Forrest (the administrator) will point to zones like slashdot, cnn,
>        etc and say they do similar things.  He is not doing anything
>        particularly unique and nothing in the specs say he is wrong...

this is probably no acceptable, people tend to like stuff like
http://cnn.com/.

> 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).

> 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.

/Jakob

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