Re: Very funny, Polyanna :-( [namespace pollution]

:Isn't this really just a special case of the more general problem of
:deciding which keys on a public key ring you're willing to trust?
:Perhaps your mailer script should automatically encrypt only when a
:keyid is found with a signature trail that you trust.

No, that's a totally separate problem.  What I'm worried about is
some comedian publishing a public key for addresses like
"alt.security.pgp@cs.utexas.edu" or any of the common mailing
gateways, and suddenly people using auto-encrypting mail programs
find that no-one can read their posts.

It kind of throws a spanner in the works for completely transparent
pgp shells.

:I do see a signature for that key from Miron Cuperman. Perhaps
:you'd want to modify your trust parameters for him...

That's not the point; someday soon people will be using mailers
that auto-pgp without them even realising it.  I don't want to
have to hassle those people with interactive questions about whether
they trust someone, or force them to maintain personal lists of
bad addresses.

Whatever solution we can find will have to involve active support
from the keyservers I suspect.  thoth@netcom - I hope you're
listening to this!  There's a definite problem of a denial-of-service
attack here that the current scheme makes hard to avoid.  Hence why
I called it 'namespace pollution' in the subject line.

G

>What I'm worried about is
>some comedian publishing a public key for addresses like
>"alt.security.pgp@cs.utexas.edu" or any of the common mailing
>gateways, and suddenly people using auto-encrypting mail programs
>find that no-one can read their posts.

Presence on a keyring means that a key exists, not that the owner of a
key has a policy that it should always be used, or that it should be
used by everybody.  Both PGP and PEM get this completely wrong.  Not
every key will be used for every purpose.  Mere existence of a key
should not indicate permission to encrypt with it.

No current cryptosystem has a way of specifying policy in a public key
distribution system.  I want separate keys for separate machines,
separate keys for signing and for secrecy, separate keys for
contracting and for authentication.  The current systems don't support
this, and will, I suspect, not support this any time soon.  In the
meanwhile such policies will have to be created manually, even if
their operation is transparent.

>Whatever solution we can find will have to involve active support
>from the keyservers I suspect.  

The key servers are just serving data.  To add policy criteria to the
key servers is to extend their functionality beyond their original
intent.

Eric