[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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


Home | Date list | Subject list