Subject: Re: About User-ID's

From: Michael Helm <[email-masked]>
Date: Mon, 20 Aug 2001 10:20:22 -0700

Derek Atkins writes:
> One solution would be to put PGP Keys (Certificates) into DNS.  Then
> you could easily lookup a key based on the userID, but you have to
> already KNOW the userID.  Unfortunately this doesn't help you lookup
> a key by KeyID.

Why is it necessary to put certs into dns in order to accomplish
this end?

---

From: Derek Atkins <[email-masked]>
Date: 20 Aug 2001 13:43:17 -0400

Who said it was necessary.  I was only suggesting it as one approach.
One of the benefits we can get by leveraging DNS is that key service
can be distributed.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Michael Helm <[email-masked]>
Date: Mon, 20 Aug 2001 10:57:59 -0700

> Who said it was necessary.  I was only suggesting it as one approach.

This statement

> > > One solution would be to put PGP Keys (Certificates) into DNS.  Then

makes the linkage look  like a mandatory requirement.

Am I right that that anything that accomplishes this is ok

> > > already KNOW the userID.  Unfortunately this doesn't help you lookup

(ie this is the  real requirement?)  We could do this by changing the
query rules on the http and ldap servers I would think.
[How] Does this render the servers unusable? What about the distributions
of pre-built databases (I am one of those).

What kinds of uses would cause someone to look up keys w/o knowing
the user id, or other handle on the key, first? 

> One of the benefits we can get by leveraging DNS is that key service

Let 's not worry about distributability for the  moment.

---

From: Derek Atkins <[email-masked]>
Date: 20 Aug 2001 14:29:43 -0400

> makes the linkage look  like a mandatory requirement.

No, it's not a requirement.  The phrase "one solution" means "this is
one approach" implying there are others.

> Am I right that that anything that accomplishes this is ok

Well, yes, but I would still like to see a distributed solution come
sooner rather than later.

> the user id, or other handle on the key, first? 

Well, I was recently looking for a friend's key because I knew he
changed jobs and his old email address didn't work.  So I searched on
last name to try to find him.  However, I probably could have used
other search methods to do that as well.

Most of the time mailcrypt will just fetch the key using the full
email address.

Perhaps searches should be limited to full-word, lhs queries (so you
can't query on 'mit.edu' but you could query on 'warlord', 'derek',
and 'atkins').  I will note that using DNS loses the ability to do
partial searches; you could only 'search' by full email.

> Let 's not worry about distributability for the  moment.

True, distributability is a separable problem.

-derek

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 20 Aug 2001 22:35:57 +0200

You can publish PGP keys in DNS right now if you like, see RFC 2538.

Since not every PGP user is trusted with maintaining the DNS
information for the zone where she lives in, I've been thinking about
PGP key "hosting" in DNS.  E.g., it would be possible to publish PGP
keys in DNS on behalf of others as "simon.josefsson.org.dnskeys.pgp.net".

One problem with publishing my PGP key under simon.josefsson.org is
that I already store my S/MIME cert there....  To save bandwidth, it
has been suggested that you could use e.g. "simon._pgp.josefsson.org"
(the dummy _pgp domain is inserted where the `@' is).