Subject: Re: I-D ACTION:draft-schlyter-appkey-00.txt

From: Ólafur Guðmundsson <[email-masked]>
Date: Tue, 04 Sep 2001 23:21:48 -0400

At 05:05 AM 8/31/2001, Jakob Schlyter wrote:

Please take a look at these two ID's both are trying to address the
the problem with sub typing of KEY records and the possibility of
large KEY RRset.

>         Title           : Storing application public keys in the DNS
>         Author(s)       : J. Schlyter
>         Filename        : draft-schlyter-appkey-00.txt
>         Pages           : 8
>         Date            : 29-Aug-01
>
>This document specifies a new DNS RR type for applications to store
>public keys in.  Experience with DNSSEC has indicated that mixing DNS
>keys and application keys is a bad idea in many regards.  The new RR
>expands certain fields based on experience from early DNSSEC
>deployment.  This document updates RFC 2535.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-schlyter-appkey-00.txt

>         Title           : DNS KEY Resource Record Generic Protocol Value
>         Author(s)       : E. Lewis
>         Filename        : draft-lewis-dnsext-key-genprot-00.txt
>         Pages           :
>         Date            : 10-Jul-01
>
>A new protocol value is defined for the KEY Resource Record which
>identifies the intended protocol as that identified in the SRV-like
>encoding of the KEY RR's owner name.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-lewis-dnsext-key-genprot-00.txt

The total solution space now is
0. Do nothing leave KEY records as is and not worry.
1. Generic Protocol value for KEY record
2. APPKEY record
3. Create a new KEY type record for every protocol that wants
    that wants to store

         Olafur

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 5 Sep 2001 10:20:08 +0200 (MEST)

> 3. Create a new KEY type record for every protocol that wants

and, even though I personally do not support it, we also have

4. use CERT record for all application keys/certificates.

some people have suggested that we add features of CERT to APPKEY and then
deprecated CERT leaving us with the infrastructure KEY type and the
application APPKEY type.

	jakob

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 5 Sep 2001 08:48:40 -0400

----- Original Message -----
From: "Ólafur Guðmundsson" <[email-masked]>
To: "DNSEXT" <[email-masked]>
Sent: Tuesday, September 04, 2001 11:21 PM
Subject: Re: I-D ACTION:draft-schlyter-appkey-00.txt

> 3. Create a new KEY type record for every protocol that wants

I think options 0 and 3 are not the front runners.  I haven't heard an
arguement for leaving the KEY record as it stands, and allocating a new type
for every protocol is just another hurdle for protcol developers.  So that
leaves options 1 and 2 and the compromise Håvard suggested (my
interpretation):  The CERT record SHOULD be used when the protocol uses a
public key and a non-DNS signature and performs verification/authentication
out of band.  An APPKEY (or some other new solution, but APPKEY is
reasonable) SHOULD be used when the application relies on using the DNS
resolver to perform authentication.  (APPKEY and a SIG record).

There are other outstand issues as well, but focusing on one at a time is a
good idea for now.

Scott

---

From: Edward Lewis <[email-masked]>
Date: Wed, 5 Sep 2001 09:26:15 -0400

Another is create a CERT RR certificate type to hold public keys.  This has
been suggested on the [email-masked] but is not documented.  (I know -
send text, but this isn't my idea, nor one I have been supporting.  But I
felt it should be added to the list here.)

>the word 'unsubscribe' in a single line as the message text body.

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D--=3D-=
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.