Re: Keys at apex problem - New PUBKEY RR?

["Scott Rose" <scottr@antd.nist.gov>]

If we decide to add a new RR for public keys, we would (should?) need to
make changes to the existing KEY

- the A/C bits in the flags would now only be used to indicate non-existance
Does anyone use NULL keys to indicate an algorithm is not supported ?(i.e.
have a RSA KEY, and a NULL DSA KEY)  since DNSSEC has no confidentiality,
the A/C bits would either always be 01 or 11.  If we are removing NULL KEYs
altogether, the A/C bits become even less useful.

- the protocol field would not be needed (always DNSSEC for KEY)

A PUBKEY RR would look like the KEY RR now:  with a protocol and algorihtm
field, but the flags would not be needed (or reduced).  I would assume the
protocol using DNS to search for a public key would know how to interpret it
in the reply.  The PUBKEY RR would be like the CERT RR now - separate from
DNSSEC.  It could even be used without DNSSEC (I know, it wouldn't be smart
to accept a key without a verified SIG).

If the two options are to disallow non-zone KEYs at the apex (via wording in
an RFC or BCP) or allowing a non-DNSSEC option, the later would give people
more freedom and means less chances of bad "DNS style".  The traffic seems
to be leaning towards a new RR for other protocol keys.

Scott


> On Thu, Apr 19, 2001 at 12:16:28PM +0200, Jakob Schlyter wrote:
> > On 18 Apr 2001, Simon Josefsson wrote:
> > 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.
> >
> > if we like to add a PUBKEY RR, we should do it now. it may be to late,
but
> > as soon as people starts using it, we're into more problems. or we
should
> > make a workaround for the apex problem, either by relocating the
> > application keys (like _ssh.host.example.org) or by ignoring the problem
> > (and therefore prohibiting application keys at the apex). relocation is
> > always an option and how it is done could be specified in a rfc on how
to
> > lookup keys for a specific application.
> I like the idea of adding a new RR more than using subzones for storing
> public keys. As we are about to remove the NULL key, why not add such
> a new RR?
>
> grtz Miek