Subject: About User-ID's

From: Ingo Luetkebohle <[email-masked]>
Date: Sun, 5 Aug 2001 15:32:39 +0200

Hello,

I would like to suggest an RFC or other document about best current
practices regarding User-ID's.

In that, a thorough re-evaluation of the current situation should be
done, possibly based upon previous works, if there are any (I'm not
aware of that, if anyone is, I'd be happy about a pointer). 

The reason for all this is that I see several problems with the way
User-ID's are used on OpenPGP implementations right now. Immediately
obvious is the spam problem because User-ID's contain e-mail addresses
and people are encouraged to upload their keys to keyservers, which
are searchable by all but also the uniqueness problem (people have
multiple addresses and I'm not of the opinion that listing them all is
the solution) and the problem of anonymity.

What does the working group think? Are the abovementioned problems
irrelevant in your opinion or, if not, would you agree that a document
about User-ID's would be a good start at solving them?

Looking forward to your input!

-- 
	Ingo Luetkebohle / [email-masked] / 95428014
/
| Student of Computational Linguistics & Computer Science;
| Fargonauten.DE sysadmin; Gimp Registry maintainer;
| FP: 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B

---

From: Jon Callas <[email-masked]>
Date: Sat, 18 Aug 2001 16:27:12 -0700

>Looking forward to your input!

I don't know about irrelevant -- but I don't know what do do about them. If
user ids didn't have email addresses on them (which they don't have to), it
would be hard to find the right key when you want to encrypt mail to
someone.

What do you think the solution is?

	Jon

---

From: Len Sassaman <[email-masked]>
Date: Sat, 18 Aug 2001 17:08:29 -0700 (PDT)

> would be hard to find the right key when you want to encrypt mail to

People have talked about the possibility of spammers harvesting names from
the keyservers for quite some time now. Out of curiousity, last May I
created a key with a unique email address and submitted the keyserver
network as bait. It's been over a year now, and I have yet to receive a
piece of spam to that address.

So, not to say that this won't happen, but I haven't seen any evidence
that is does currently.

Len

--

Len Sassaman

Security Architect            |
Technology Consultant         |  "Let be be finale of seem."
                              |
http://sion.quickie.net       |           --Wallace Stevens

---

From: Ingo Luetkebohle <[email-masked]>
Date: Sun, 19 Aug 2001 12:59:37 +0200

> would be hard to find the right key when you want to encrypt mail to

Oh, I didn't mean to suggest that. Sorry for not making that clear.

I think "best practices" can be divided in two: 1) best practices on
what to put into a User-ID (obvious and well-established for e-mail,
could be different for SSL keys and so on) and 2) best practices on
how software treats the information.

For an example of the latter, I think current key-server software
makes it exceptionally easy to harvest e-mail address, should someone
desire to do so. I can search for three random letters to get all keys
with those three letters in and the HTML page I get conveniently lists
not just the matching keys but also all the e-mail addresses, *and* --
with the right options -- all e-mail addresses of all signers. This
allows a smart crawler to easily walk the whole server and gather
addresses -- *just* addresses.  Now just consider how much more
difficult it would be if the crawler would have to download the key,
interpret it, go back to the keyserver to fetch all keys referenced in
the signers section and so on. This could be forced by a slight change
in the amount and nature of information revealed by the key-server
(e.g., it could just display the key-id, and the number of
signatures). For legitimate users, who have to download the whole key
anyway, it wouldn't make a difference.

This could be summed up in a suggestion of a best practices document
that software should expect keys to contain sensitive information and
be careful in what it exposes.

There are obviously more open questions, some of which have
traditionally been in FAQ's. Maybe it would help if I draft a small
document with all of them and we can then decide of whether to make an
information RFC from it or just leave it to application developers
documentation?

Regards

--
	Ingo Luetkebohle / [email-masked] / Student of Bioinformatics
/
| Cross-Platform OpenPGP: http://xpg.sourceforge.net/
|
| Fargonauten.DE sysadmin; Gimp Registry maintainer;
| FP: 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B

---

From: Werner Koch <[email-masked]>
Date: 19 Aug 2001 19:00:57 +0200

> So, not to say that this won't happen, but I haven't seen any evidence

People who are currently using PGP keys are not a valuable audience
for spammers. 

If in the future it is common to use encryption, spammer will have a
serious problem: They can't use an open relais to send their trash and
save on their on bandwidth - they would have to get the key of each
recipient, encrypt to this key and send them utilizing there own
resourses.  This will be far too expensive for the common mass spam
attacks.  Yes, I assume that every MTA will at that time drop non
encrypted mail ;-)

  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus

---

From: Michael Helm <[email-masked]>
Date: Sun, 19 Aug 2001 19:29:27 -0700

> People who are currently using PGP keys are not a valuable audience

I suspect it's more a matter of ignorance about mining the data
than anything else.

Could keys and keyservers be configured [optionally] not to
present email-like id's?

---

From: "Michael Young" <[email-masked]>
Date: Mon, 20 Aug 2001 11:07:53 -0400

-----BEGIN PGP SIGNED MESSAGE-----

From: "Michael Helm" <[email-masked]>
> Could keys and keyservers be configured [optionally] not to

Not without almost completely impairing their use.  Yes, it
would be easy to turn off name-based lookups, and/or discard or
alter UserId packets.  But...

If you remove or irreversibly alter the UserID material, then:
(1) associated signatures will fail to verify; and, (2) e-mail system
plug-ins will be unable to do matching.  If you alter them in a way
that is automatically reversible, then any harvester could undo the
alteration just as easily.  You would also have to teach all the
existing tools to undo the alteration(s).

Note that many people use altered addresses in their posts, with the
expectation that they'll be fixed *manually*.  A few people (myself
included) do that for keys they upload.  If the alteration doesn't
affect "words" in the name, then name-based lookups will work against
all?) current keyservers.  Plug-ins may require a more exact
match... since I don't use any, I wouldn't know for sure.  Again,
a smart harvester might use some heuristic de-mangling that would
generate a valid address, but that's a risk I'm willing to live with.
Any "mangling standard" might make it more worth trying.

---

From: Ingo Luetkebohle <[email-masked]>
Date: Mon, 20 Aug 2001 19:33:41 +0200

On Mon, Aug 20, 2001 at 11:07:53AM -0400, Michael Young wrote:
> If you remove or irreversibly alter the UserID material,

Altering the *real* UserID material is probably not a good
idea. However, you can do a lot on the presentation layer. A keyserver
could allow searching for e-mail addresses (even with substring
search) but not *display* them (or display them in a mangled way).

This helps prevent "tree walking" because knowledge of the content
would be required to retrieve it.

Regards