To:
Simon Josefsson <simon+dnssec@josefsson.org>, Jakob Schlyter <jakob@crt.se>
Cc:
Derek Atkins <warlord@MIT.EDU>, Scott Rose <scottr@antd.nist.gov>, <dnssec@cafax.se>
From:
Ólafur Guðmundsson <ogud@ogud.com>
Date:
Thu, 06 Sep 2001 14:25:09 -0400
In-Reply-To:
<ilu7kvezr3l.fsf@barbar.josefsson.org>
Sender:
owner-dnssec@cafax.se
Subject:
Re: CERTificates and public keys
At 03:35 PM 9/4/2001, Simon Josefsson wrote: >Jakob Schlyter <jakob@crt.se> writes: > > > I'm not sure how we can move forward on this discussion - we either have > > people who think it's misuse to put raw public keys in CERT and people who > > doesn't think there is a problem with doing that. > >It is already possible to put a public key that is not signed by a CA >in a CERT record. Let's use it. DNS lesion: sub typing is BAD BAD BAD, If I had to do CERT record over again I would have a different RR type for each CERT type. Lets not stuff more things into CERT RR that are not CERT's (And the real security mafia will stab you in the back if you somehow decrease the security integrity of Certificates, just like they did to me when TSIG was called "Transaction Signature"). 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) 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. I, in general do not see any problem with having both APPKEY and CERT records for use by applications as long as the goal is for each application to use ONLY ONE of the two. But there will be applications like IPSEC where CERT is specified but people will try to escape from the extortion/certificate authorities thus migrating to APPKEY. Olafur