Re: Keys at apex problem - New PUBKEY RR?

[Edward Lewis <lewis@tislabs.com>]

Why does it seem that all the interesting discussions happen when I'm
travelling?

Here are my $.02 (US):

1) There is nothing really broken with the current KEY RR holding
non-DNSSEC keys even at the apex.  True, putting, e.g., IPSEC keys at the
apex and getting them signed by the parent is ill advised, but the protocol
will work for this.

2) There is an installed base of code that implements the current specs on
this - BIND 9!  No, not many applications, but enough has been done to make
me shy away from advocating a redefinition of anything.

Recommendations:

Do not change the protocol specification of the KEY RR.

Do not make the handling of non-zone keys at the apex a special case.

Don't hijack the CERT record from its current role.

Do discourage non-zone keys in the apex KEY by offering an alternative.  Of
the two alternatives, the PUBKEY and the application naming convention, one
should be eventually choosen - which one I cannot say now.

Do recommend against using the KEY at the apex to store non-DNSSEC keys,
but allow it.  (It's acceptable to me for a registr* to charge for such
keys.)

My thoughts on the PUBKEY vs. naming convention:
PUBKEY can coincide with KEY, even use the same syntax.  You could even
think of PUBKEY as simply a "cname" to KEY definition wise ;).  This
doesn't end the subtyping issue however, although now I can put my
non-DNSSEC apex keys in PUBKEY and just send the KEY set to the parent.
(This approach would speed time to specification and implementation.)  One
spec caveat here - recommend that only zone keys be in and be put in the
KEY, all others be in and be put in PUBKEY.

The naming convention keeps rising in conversations, but I've never seen it
succeed.  (I've never seen it be an utter failure.)  One question: should
the names be something like:
         cnn.example.  SOA
                       A
         _ipsec        KEY
         _ssh          KEY
         www           A
         _ipsec.www    KEY
or

         cnn.example.   SOA
                        A
         www            A
         _ipsec.key     KEY
         _ssh.key       KEY
         _ipsec.www.key KEY

?  (Should the keys be in one subdomain?)

The former (PUBKEY) is quicker to acheive but still has subtyping (which
complicates resolution).  The latter increases names in a zone but removes
the subtyping issue.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: lewis@tislabs.com

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.