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
participants (2)
-
gtoal@an-teallach.com -
hughes@ah.com