1994-12-01 - Re: Warm, fuzzy, misleading feelings

Header Data

From: eric@remailer.net (Eric Hughes)
To: cypherpunks@toad.com
Message Hash: 947c9287d26fe34970fd77a47181f01f1259a5aaeff141f7ff7aab69184063b9
Message ID: <199412012055.MAA13646@largo.remailer.net>
Reply To: <199412010957.BAA23404@netcom3.netcom.com>
UTC Datetime: 1994-12-01 19:57:04 UTC
Raw Date: Thu, 1 Dec 94 11:57:04 PST

Raw message

From: eric@remailer.net (Eric Hughes)
Date: Thu, 1 Dec 94 11:57:04 PST
To: cypherpunks@toad.com
Subject: Re: Warm, fuzzy, misleading feelings
In-Reply-To: <199412010957.BAA23404@netcom3.netcom.com>
Message-ID: <199412012055.MAA13646@largo.remailer.net>
MIME-Version: 1.0
Content-Type: text/plain


   From: tcmay@netcom.com (Timothy C. May)

   More that just making crypto look stupid, [... it] defeats
   the whole purpose of user-to-user verfication.

Solutions that are bottom up are fine so long as they're not required
to remain on the bottom.  If a service (not the one I'm proposing)
were to actually verify sigs, then some people might want to trust it
and some might not, depending on their desires and abilities.

   I'm interested in systems which actually allow me to _really verify_
   sigs if I have to [...]

And so am I.  There is less incentive, however, to set up a sig
checker when there are few signatures to check.  I don't think we need
the whole crypto world to come into bloom at once.  In fact, I don't
that _could_ happen and that expecting that sort of parallel
development is a positive hindrance to deployment.

   I wasn't kidding earlier today (apologies that I'm reading the later
   mail first, as I just got home) when I argued that toad messages ought
   to be signed. That is, all traffic from toad. 

I didn't think you were kidding, nor did I think that the PGP
deficiency you pointed out was trivial.

There have been major issues about trustability at toad.com and it is
inappropriate at the current time to consider trusting signatures it
might make.  Again, I don't feel that this problem needs to be solved
in order to encourage people to use digital signatures.

   If sigs are to be compelled [or bounced ...], then such sigs
   should *actually be checked*, with the resulting checked messages then
   signed by toad/Eric/Hugh/John/whatever.

There is some merit to this idea, assuming that signatures are to be
used as access control.  The current proposal, however, does not
include that and hence the argument above is premature.  I'd like to
examine it later at some point when it is more timely.  In the
interim, though, I leave with an open question: "What would such a
server signature represent?"

   Anything less than this is actually counterproductive, as it fosters
   a non-Cypherpunkish view of placing trust in others to do what
   technology allows one to do directly.

Another non-Cypherpunkish view is to prevent the creation of systems
which allow you to use an agency relation to let someone else do
something for you.  For reading cypherpunks mail on a slow machine, or
someone else's machine, I'd be glad to use an agent (the legal
denotation here) to verify signatures.

What is definitely non-Cypherpunkish is to promote systems that
require trust relations that would not be entered into freely, like
the first PEM certificate mechanism.

Eric





Thread