To:
"Loomis, Rip" <GILBERT.R.LOOMIS@saic.com>
Cc:
"'Jakob Schlyter'" <jakob@crt.se>, Derek Atkins <warlord@MIT.EDU>, Scott Rose <scottr@antd.nist.gov>, dnssec@cafax.se
From:
Simon Josefsson <simon+dnssec@josefsson.org>
Date:
Tue, 04 Sep 2001 22:12:05 +0200
In-Reply-To:
<3C1E3607B37295439F7C409EFBA08E680E267F@col-581-exs01.cist.saic.com>("Loomis, Rip"'s message of "Tue, 4 Sep 2001 13:29:35 -0400")
Sender:
owner-dnssec@cafax.se
User-Agent:
Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.0.105
Subject:
Re: CERTificates and public keys
"Loomis, Rip" <GILBERT.R.LOOMIS@saic.com> writes: > - Keys/certificates which include their own > authentication information/methods, and > which can benefit from (but do not rely > on) DNSSEC [handled in CERT RR] CERT also handles self-signed certificates and CRLs. > Personally I would prefer that there be only one type of record > which DNS servers use to support "all the other keys" rather than > having both CERT and APPKEY...it seems cleaner, and it allows DNS > administrators (and implementors) to avoid worrying about the > differences. If it's a DNSSEC key for the zone, then it goes into a > KEY RR. If not, it goes into the other catch-all, and all the folks > who want to do complicated neato whizbang things in applications can > do those things outside of the DNS implementations. Yes! This is what I want. The KEY RR is for internal DNSSEC only, and some other RR for keys used by non-DNSSEC. I believe the easiest way to implement this "other RR" is by using the CERT RR and recommending applications to register their own certificate type number and put whatever makes them as the data blob. Applications that store raw public keys would of course need the security services of TSIG, DNSSEC, IPSEC etc as well. Deprecating CERT and using APPKEY instead would also work fine But having both CERT and APPKEY used by applications would be confusing.