Subject: [Enum] Public Keys in ENUM

From: "Stastny Richard" <[email-masked]>
Date: Wed, 12 Jun 2002 12:32:41 +0200

Hi folks, Patrik,
 
In my recently submitted draft-stastny-enum-services-analysis-00.txt (not yet officially announced, but already available in the directories) I propose in sections 4.3 and 4.4 also enumservices related to public keys (e.g. "ldapkey" and "cert"), assuming that e.g. an ldap: URI is pointing to the public key of the holder of the ENUM domain.
 
I also raise the question, if there is an URI scheme or another possibility to store the public key directly in an ENUM domain and what would be the preferred method?
 
IMHO this could be a nice (killer?) application for ENUM and also for a global PKI.
 
best regards
 
Richard Stastny
mailto:[email-masked]
tel:+436644204100

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 12 Jun 2002 23:05:56 +0200

--On 2002-06-12 12.32 +0200 Stastny Richard <[email-masked]>
wrote:

> In my recently submitted draft-stastny-enum-services-analysis-00.txt (not
> yet officially announced, but already available in the directories) I
> propose in sections 4.3 and 4.4 also enumservices related to public keys
> (e.g. "ldapkey" and "cert"), assuming that e.g. an ldap: URI is pointing
> to the public key of the holder of the ENUM domain.  
> I also raise the question, if there is an URI scheme or another
> possibility to store the public key directly in an ENUM domain and what
> would be the preferred method?

The view by DNS people in IETF in general, and the DNS Directorate (of
which I am a member) is that DNS is not to be a kitchen-sink for storage of
data. That should be done in various suitable directory services.

DNS MIGHT though contain pointers to where the data is.

So, I would like to say that storing the keys/certificates directly in DNS
will get a "no no" answer from DNS people, while having a specific LDAP URI
in an NAPTR record and that LDAP URI is what you use to fetch the cert/key
is ok. Of course, something else than LDAP can be used as access protocol,
but the key point is that the key itself is not stored in DNS.

Just my $0.02.

   paf

---

From: David Conrad <[email-masked]>
Date: Wed, 12 Jun 2002 14:39:29 -0700

On 6/12/02 2:05 PM, "Patrik Fältström" <[email-masked]> wrote:
> will get a "no no" answer from DNS people,

I guess I'm not a DNS person then.

Rgds,
-drc

---

From: Jim Reid <[email-masked]>
Date: Wed, 12 Jun 2002 14:58:00 -0700

>>>>> "paf" == =?ISO-8859-1?Q?Patrik F=E4ltstr=F6m?= <ISO-8859-1> writes:

    paf> The view by DNS people in IETF in general, and the DNS
    paf> Directorate (of which I am a member) is that DNS is not to be
    paf> a kitchen-sink for storage of data.

Isn't acting as a kitchen sink for data the sole purpose of the DNS... :-)

    paf> So, I would like to say that storing the keys/certificates
    paf> directly in DNS will get a "no no" answer from DNS people,

Including the DNS people who invented the CERT record? :-)

I would have thought that it would be cleaner and more elegant to just
do a DNS lookup and retrieve a PGP or SSH key (say) instead of getting
back the name of some server to then query with some other protocol to
get that data.

---

From: Michael Mealling <[email-masked]>
Date: Wed, 12 Jun 2002 18:10:54 -0400

> back the name of some server to then query with some other protocol to

It might be cleaner for that particular application if it were the only
one but it isn't. The rule of thumb I've heard used and which I particular
adhere to is this: the DNS is used for pointing to where the information
you are after can be found, not containing it. For ENUM this means that we 
put the URIs in there, not the information in the resources they point too.

In the URI Resolution application we made sure that the granularity of
what was in DNS was still at the host or node level, not the content level.
I.e. there should never be a 1:1 correlation between the number of URIs
for a site and the number of DNS records in its zone. 

For certificates this means that while it may be fine to contain a CERT
for a given host, its not OK to put all of the CERTS for the users 
that may inhabit that host....

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net

---

From: David Conrad <[email-masked]>
Date: Wed, 12 Jun 2002 15:35:10 -0700

Needless to say, this is a controversial topic.  It also isn't particularly
relevant to ENUM.  For those interested in this sort of thing, there is a
mailing list, [email-masked], where discussions related to putting keying
information in the DNS occur.

I'd strongly recommend continuing the discussion there.

Rgds,
-drc

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 13 Jun 2002 08:59:27 +0200

--On 2002-06-12 14.39 -0700 David Conrad <[email-masked]> wrote:

>> So, I would like to say that storing the keys/certificates directly in
>> DNS will get a "no no" answer from DNS people,
> 

You are David Conrad, and yes, I count you as a DNS person.

Yes, I know you have a different view, but, I must still say this is the
message I get from for example chairs of DNSEXT and DNSOPS and other people
in the DNS Directorate.

  paf

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 13 Jun 2002 09:02:33 +0200

> back the name of some server to then query with some other protocol to

As you DNS persons (yes, David included ;-) there are several very
"unpleasant" discussions about keys, certificates in DNS at the moment.
Appkey being one. CERT record being another. (Re-)use of KEY record for
non-DNSSEC issues etc.

I suggest ENUM should follow the result/outcome in that discussion, and
throw yet another log into the fire.

Part from this, I think ENUM as a mechanism for storing pointers to
"things". The pointers are in the form of URI's. So, one can with ENUM have
in DNS a pointer (URI) to the cert one want to expose.

This I think is perfectly alright.

   paf