To:
Jakob Schlyter <jakob@crt.se>
Cc:
Simon Josefsson <simon+dnssec@josefsson.org>, "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com>, Derek Atkins <warlord@MIT.EDU>, Scott Rose <scottr@antd.nist.gov>, <dnssec@cafax.se>
From:
Simon Josefsson <jas@extundo.com>
Date:
Tue, 04 Sep 2001 22:39:10 +0200
In-Reply-To:
<Pine.BSO.4.33.0109042222080.15752-100000@fonbella.crt.se>(Jakob Schlyter's message of "Tue, 4 Sep 2001 22:24:12 +0200 (MEST)")
Sender:
owner-dnssec@cafax.se
User-Agent:
Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.0.105
Subject:
Re: CERTificates and public keys
Jakob Schlyter <jakob@crt.se> writes: >> 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 > > combining the application part of KEY and the certificate part of CERT > into APPKEY could work. Yes. That would be a good solution. (Assuming the CERT RR is deprecated in favor of the APPKEY RR.) >> But having both CERT and APPKEY used by applications would be >> confusing. > > how would that be confusing? would your PKI application suddenly start > quering for a raw public key? No -- applications would not be confused, but as a application designer who wants to put keys or certificates in DNS, at least I would be confused. Should I define a CERT RR certificate type or a APPKEY type? If they both accomplish roughly the same thing, why should there be two approaches? I'm trying to say that one RR should be enough to support public key stuff in applications. If it is APPKEY or CERT doesn't matter to me. (But one of them has been around for a while, so maybe it would cause less trouble to use that one..)