Re: Keys at apex problem - New PUBKEY RR?

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

----- Original Message -----
From: "Ted Lindgreen" <ted@tednet.nl>


> [Quoting Dan Massey, on Apr 19, 22:14, in "Re: Keys at apex pro ..."]
>
> > .....
>
> Your analysis looks spot on to me.
>
> > So I guess that is the very long way of saying I'm in favor of
> > separating DNS infrastructure keys from application keys. I think
> > either CERT only or CERT+PUBKEY would work, but I don't know which
> > of those two is better.
>
> Yes, I think you are right.
>
Looking at the CERT description (RDATA format), it has a very similar
structure to the KEY record.  The same fields needed by a PUBKEY record are
found in the CERT.  I do not know how widely deployed the CERT record is,
but most DNS implementations know how to handle it.  I do feel a bit uneasy
of "taking over" the CERT record to use with public keys (which are not
certificates in themselves, but with a SIG, maybe they are ;-)

So the arguement for CERT would be:
1.  Already defined - easy to create an SSH, IPSEC, whatever  type
2.  No need to define another RR type with similar properties as KEY and
CERT (the PUBKEY RR)

against:
1.  Already deployed for certificates, not just keys (violating the intended
use of the CERT RR).
2.  Have to modify existing DNS implementations and other apps that use KEY
queries.

> >From the three alternatives I see:
>
> 1. Live with non-zone-KEY RRs in the apex.
> 2. Separate KEY RR usage (KEY in apex is zoneKEY and zoneKEY only,
>    KEY RRs outside apex are for other usage), and try to enforce
>    this usage by SHOULD of MUST.
> 3. Limit the KEY RR usage to zoneKEY only and use some other RR
>    for anything else.
>
> number 3 certainly looks the cleanest.
>

Since Dan and I are just "editors" and cannot make any changes without
concensus, if the WG things option 3 is the way to go, I'm all for it.  One
thing that will be an issue is the sudden useless fields in the KEY RR if it
is to be made DNS protocol only.  The spec will seem odd having a field set
to a constant value of 3 (DNSSEC protocol value in KEY).  We should change
that if we are going to be serious about spliting KEY into a DNS KEY RR and
other protocol PUBKEY or CERT.

Scott


> Regards,
> -- Ted.