To:
Jakob Schlyter <jakob@crt.se>
Cc:
<Ted.Lindgreen@tednet.nl>, Dan Massey <masseyd@isi.edu>, <dnssec@cafax.se>
From:
Simon Josefsson <simon@josefsson.org>
Date:
19 Apr 2001 15:07:00 +0200
Delivery-Date:
Fri Apr 20 07:49:24 2001
In-Reply-To:
<Pine.BSO.4.33.0104191209220.6456-100000@fonbella.crt.se> (Jakob Schlyter's message of "Thu, 19 Apr 2001 12:16:28 +0200 (CEST)")
Sender:
owner-dnssec@cafax.se
User-Agent:
Gnus/5.090003 (Oort Gnus v0.03) Emacs/21.0.102
Subject:
Re: Keys at apex problem
Jakob Schlyter <jakob@crt.se> writes: > > One solution that wouldn't require changing specifications nor > > implementations, and would remove this problem, would be to mandate a > > practice (both in the SSH DNSSEC-patches as well as with the zone file > > administrators) to add ssh KEY RR's as "_ssh.host.example.org" or > > something similar. > > is there a problem changing the specs when there are no widely deployed > implementations? the only applications I know of that are using KEY is > isakmpd and fmeshd's ssh. Are there really any specs to specify location of KEY's for a host? I've written a draft to specify location of CERT RR's (which updates RFC2538 owner name guideliness), and I looked for similar drafts on KEY locations but didn't find any. I think the location of a KEY record for a host has been simply assumed by everyone to be the DNS hostname. Anything else would be weird, but this thread shows that the obvious solution has its problems as well. > if we like to add a PUBKEY RR, we should do it now. What would PUBKEY do that KEY can't do? Three ways of doing roughly the same thing - KEY, CERT and PUBKEY - seems a little bit too much. IMHO the simplest thing would be to say that KEY is only used for DNSSEC internally, and other applications should use CERT (it's easy to define a CERT SSH type), and the CERT standard should also be separated from the DNSSEC standard because it really doesn't depend on it. Perhaps, I dunno.