To:
Roy Arends <Roy.Arends@nominum.com>
Cc:
Wesley Griffin <wgriffin@tislabs.com>, <dnssec@cafax.se>
From:
Simon Josefsson <simon+dnssec@josefsson.org>
Date:
Fri, 06 Jul 2001 23:22:37 +0200
Delivery-Date:
Sun Jul 8 21:39:25 2001
In-Reply-To:
<Pine.BSF.4.33.0107062228450.23578-100000@node10c4d.a2000.nl>(Roy Arends's message of "Fri, 6 Jul 2001 22:46:35 +0200 (CEST)")
Sender:
owner-dnssec@cafax.se
User-Agent:
Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.0.103
Subject:
Re: SSH keys in DNS
Roy Arends <Roy.Arends@nominum.com> writes: > This approach has its up and downsides. Upsides are for instance being > able to store all pgp related material in a single subzone. Downsides are > PGP specific, and have nothing to do with presentation format. I see an standardization "issue" with this _appX.foo.example.org approach, and I'm not sure if it's an advantage or disadvantage. By storing stuff in the owner names, the "algorithm" field in the KEY RR is basicly replaced. I mean, applications will start to use owner names to differentiate between different kind of KEYs, instead of the "algorithm" field. This could be good, the algorithm field is only 8bit while owner names allow for more values, so there's no need to go through IANA and reserve a bit in the DNSSEC RR's. Also, one MAJOR feature of moving this stuff into the owner name is that the client can actually ASK for a specific KEY, instead of parsing through all responses looking for the KEY with the right "algorithm" field. Storing application keys in DNS doesn't scale well with the current model. But this might be bad, if applications are going to use owner names for differentiate the meaning of the RR, this should probably be standardized somewhere for interoperability. Where? BCPs? But what this means is that we're replacing the well-defined IANA procedure for the "algorithm" field with something less well-defined. Should IANA register "well known application domain names"? I have a feeling that the _ssh2, _pgp etc stuff is re-inventing and replacing the "algorithm" field. Perhaps I'm the only one that didn't see that coming, and if so, fine, but otherwise perhaps it needs some pondering on how this idea should stand wrt the "algorithm" field. (Hm... storing the KEY's used for DNSSEC with it's Key ID embedded in the owner name would also solve the recently discussed TTL problem... you would ask for _dnsseckey4711.example.org if you wanted example.org's KEY with Id 4711...)