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

From: Eric Hughes <hughes@ah.com>

	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.

So?  It has to be done *sometime* by someone.  The point I was making
was that for pgp (or any equivalent cyphered mail system) to work *en
masse*, it has to be completely automatic and idiot-proof.  I'm not
talking about *us* here, I'm talking about your old mother, or Mac
users, or the company technophobic managing director etc.  What I see
as desirable for such people is that their mail is encrypted whenever
possible, but they don't have to do anything to make it happen.  This
means that the current web of trust scheme is not an applicable model,
because these people have defined *no* trusted paths at all.

We need some relatively trustworthy mechanism for getting pgp keys
that will foil a denial-of-service attack - either the one I suggested
where someone sets up a key for a mailing list or mail2news gateway
(either maliciously or accidentally as with our friend Paulie-Anna)
- or where someone creates a key for a specific person (as one joker
did for Sternlight last year (this was a second one; Sternlight had
one of his own first which he never revoked before he deleted his
private key...)) which means that person won't be able to receive
mail - if auto-pgp mechanisms become common.

To me it looks like this has to be done by heavy-handed control
coming from the keyserver admins, though I'd prefer that there
was a more democratic way.  Please suggest anything you think is
appropriate...

For the moment, I think that an auto-pgp mechanism will have to
use a relatively secure server like SLED that can't have arbitrary
keys added to it by all and sundry.  If this is sufficiently
different to the current key server mechanism that Eric doesn't
object, then fine :-)  Actually, the mechanism I forsee for doing
this sort of thing is the tcp/ip interface to a keyserver that
Ben Cox suggested last november.  It *could* be bolted on to the
finger server at wasabi, but I think the whole concept needs us
to stand back a bit and think of what we really want before we
start hacking.


One mechanism that crossed my mind - when a new key is added, the
keyserver that gets it first might hold on to the new key until
after it had mailed the key owner and requested confirmation.  This
ought to be possible to automate.  This would also block the cases
where someone bulk uploads their keyring with keys on it which
they'd been given in confidence, by people who didn't want their
employers or government to know they were using pgp...

Graham

PS cc'd to alt.security.pgp - would the cypherpunks interested
in this thread follow it there with me please?

Gtoal@an-teallach.com said:
>     What I see
> as desirable for such people is that their mail is encrypted whenever
> possible, but they don't have to do anything to make it happen.  This
> means that the current web of trust scheme is not an applicable model,
> because these people have defined *no* trusted paths at all.

No, you want to give the user the option to sign and/or encrypt the
message.  Just like I can optionally sigh a letter, or optionally
write it on a postcard vs. putting it in an envelope.  It should be an
option, not a mandate.  It *shouldn't* be automagic.  It should be
configurable.  It should give the user a choice.  Maybe that user
decides "encrypt all the time"...  That is his/her perogative to do
so.

> We need some relatively trustworthy mechanism for getting pgp keys
> that will foil a denial-of-service attack - either the one I suggested

No, this is not a reasonable goal.  No, let me rephrase that.  This is
a reasonable goal, but the current implementation of PGP is not the
answer.  If you want zero-knowledge authentication of total strangers,
then you *require* a certification hierarchy, and the most effiecient
is one similar to that defined in RFC 1422.

PGP has a more grass roots method of determining key validity.  Let me
give you an example where PGP *works* -- Today.  Say, for example,
that I own a retail store.  I print my key on all my receipts, and
anyone can get it.  It is published widely, so basically there is no
easy way to spoof it.  But this doesn't matter.  The only reason I use
my key is because I want to be able to certify customer's keys.  Ok, a
customer comes in and gives me, somehow, a credit-card and a PGP key.
I can validate the credit card, and if it validates, then I sign this
key.  Now, anytime this person wants to buy something, all they have
to do is sign an order slip with their key, and I can validate it, and
I know that this is a "valid" customer.

There is no way to perform a denial of service attack (except load me
down with bogus email, but lets disregard that attack).  You can't
forge a PGP key, and I only accept keys that I've certified myself.

Ok, maybe you don't like that idea.  Ok, say that VISA starts signing
PGP keys for it's customers.  I can get the VISA Public Key directly
from VISA, then I know that any key signed by VISA is a valid key, and
I should accept orders from them.  Same thing.  No way to spoof it.

However, all of these require some out-of-band communication to make
sure you have the real key.  Unfortunately, *every* Privacy Enhanced
Mail system has this *feature* (or mis-feature, or bug, or however you
feel like looking at it).

> To me it looks like this has to be done by heavy-handed control
> coming from the keyserver admins, though I'd prefer that there
> was a more democratic way.  Please suggest anything you think is
> appropriate...

Basically, what you want is the RFC 1422 Certification Tree.  With
that tree, you can verify the authenticity of a key with zero
knowledge about that tree.  The only knowledge you need to know a
priori is the root key of the tree.

Before many people start responding to me saying that the 1422 CA Tree
is a Bad Thing, let me state for the record that I believe that there
are valid uses for the tree.  What Graham wants is a valid usage of
the tree.  What I am saying, however, is that there are other uses for
other trust mechanisms.

Graham: It is not the keyserver's job to certify keys.  It never has
been, and I still believe that it shouldn't be its job.  However, it
sounds like you are requesting that PGP have imbedded in it knowledge
about the RFC 1422 Hierarchy.  I believe this is a valid goal, and
should be pursued.  In fact, the PEM-DEV group is looking at adding
alternative turst models to the PEM system, which would merge the
current PGP web-of-trust model with the current PEM Strict Hierarchy
model, blending them into something which will solve both Graham's
problem of zero-knowledge trust, and also allow my retailer example to
work without all the overhead of applying to ISOC to get into the
tree.

What do people think?

-derek

         Derek Atkins, SB '93 MIT EE, G MIT Media Laboratory
       Member, MIT Student Information Processing Board (SIPB)
    Home page: http://www.mit.edu:8001/people/warlord/home_page.html
       warlord@MIT.EDU    PP-ASEL     N1NWH    PGP key available

>However, all of these require some out-of-band communication to make
>sure you have the real key.  Unfortunately, *every* Privacy Enhanced
>Mail system has this *feature* (or mis-feature, or bug, or however you
>feel like looking at it).

I feel like looking at it as a necessity.  Every system for
dissemination of public keys requires at least two paths of
communication.  If there is only one, an interposer can sever the
connection graph of key assurances and create two different key
worlds.

Eric