To:
Ólafur Guðmundsson <ogud@ogud.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:
Thu, 6 Sep 2001 23:01:30 +0200 (CEST)
In-Reply-To:
<5.1.0.14.2.20010906135637.02764030@localhost>
Sender:
owner-dnssec@cafax.se
Subject:
Re: CERTificates and public keys
On Thu, 6 Sep 2001, Ólafur Guðmundsson wrote: > APPKEY with SRV naming is the best solution that I have seen for > applications because > 1. it keeps key sets small (only one application related keys in > each set) thus minimizing the work in applications while > searching for the relevant record. > 2. It allows for version handling (by changing name) How is this better than using e.g. CERT with SRV naming? APPKEY is also sub-typed. CERT with SRV naming also meet your requirements, as far as I'm able to tell. If APPKEY is supposed to be CERT Done Right, which I think would be a nice goal for it, should it repeat the presumed mistake of sub-typing? > The alternative solution in my mind is to use NEW RR type for each > application but due to DNS server and resolver frequent lack of support > for new RR types this is not a good solution. *ponders* So if I understand correctly, CERT is flawed because it uses sub-typing. APPKEY using SRV naming is "better" (altough I fail to see how) but still uses sub-typing, so with the same reasoning it wouldn't be good either. New RRs is better but would be harder to put into use because of implementation issues. This suggests that no method of storing application keys or certificates in DNS is satisfactory, and that they simply shouldn't be stored in DNS. Is everyone happy with that conclusion? Maybe an agreement of one of the suggested methods can be made instead. After this thread I don't care much about which one, just as long as there is one. But considering that CERT exists and is implemented, I think it is a good candidate.