Re: ADMIN: proposed new policy on the mailing list

So far I have received six comments on the proposed sign-or-delay
system, two in public, four in private.  All have been supportive of
concept, but there have been specific technical issues with it.

-- security of keys at machines owned by someone other than the key owner.
-- standardization and legality of software

What I left out of my first posting was the particular algorithm used
at the server to verify signatures.  I was certainly going to accept
both PGP and PEM formats.  However, I had toyed with not using actual
crypto at all, but just recognizing message formats.

Given the objections I've received, I now amend my proposal from "sign
your messages, or else" to "make something that looks like a
signature, or else".  This has several consequences that I
particularly like.

The real goal of this plan is to change the software infrastructure so
that crypto can easily be inserted.  Certainly some software module
will be the only good way to create signed-format messages, and this
software, whatever it actually is, fits in exactly the same place that
real crypto does.  If, for some reason, a user does not use real
crypto but a replacement, their own system still supports crypto when
it is feasible or available or legal or whatever.

This modified plan addresses the legal issues, since a crypto-format
is not cryptographic.  In fact, it is exportable, since it is not
crypto.  There are no patent issues, since a crypto-format does not
use RSA.  It also addresses the key security issue, since there need
be no key involved.  It also implies no particular policy of key
distribution or verification, sticky issues that plague both PEM and
PGP.

Ironically, allowing pseudo-signatures _increases_ the real use of
cryptography, since no longer will there be the presumption that
because the message looks signed that it is actually signed by the
claimed signer.  The whole point of digital signatures is to allow a
verification mechanism, but using a permissive format creates the need
to use that mechanism.  Since no verification will be done at the
server, any verification desired will have to be done at the receiving
end.

There is the opportunity for a great rhetorical coup here.  Assume
that pseudosignature software exists.  Now there can be made the
argument to David Sternlight, who is nominally in favor of crypto but
who picks the least crypto-favorable interpretation of anything, to
show his support for crypto in theory but not in practice.

Comments?

Eric

>So far I have received six comments on the proposed sign-or-delay
>system, two in public, four in private.  All have been supportive of
>concept, but there have been specific technical issues with it.
>
Perhaps I wasn't clear.  The concept I support is encouraging signatures,
not some "sign or delay" scheme.  I think such schemes don't really help
encourage the use of signatures as much as they exclude people who
live in the wrong place or who don't have the right computers.  And a
"make it look signed or delay" scheme is even worse.  It just encourages
people to either give up on the list and go back to some place where the rules
make more sense or, even worse, waste their valuable time writing code that
produces funny "psuedosignatures" that serve no valuable purpose.

A much better way to spread cryptography is to work on developing new
and transparent mechanisms that help regular people securely integrate
signatures and encryption into their routine work without having to do
anything special or different. 

Trying to make life more inconvinient for people who already identify
themselves as "cypherpunks" but who for whatever reason don't have easy
access to the right tools seems not the way to do it.

-matt

Why not create a new key on one's multiuser public unix box specifically
for cypherpunks? Then you can sign as many messages on your box as you want
and not care if anyone gets the secret key since the key will not be trusted
by anyone else. Messages posted by you will be understood to be signed
by you with the possibility that someone snooped your private key
and is pseudospoofing. Is the security of this any less than we currently
have? Not really, pseudospoofing can be done by a unix novice user.



-- Ray Cromwell        |    Engineering is the implementation of science;    --
-- EE/Math Student     |       politics is the implementation of faith.      --
-- rjc@gnu.ai.mit.edu  |                         - Zetetic Commentaries      --

You write:

>So far I have received six comments on the proposed sign-or-delay
>system, two in public, four in private.  All have been supportive of
>concept, but there have been specific technical issues with it.

I think you are reading those replies through rose-colored glasses.
They were politely telling you "no way."

>The real goal of this plan is to change the software infrastructure so
>that crypto can easily be inserted. 

Please keep in mind that it is impolite to _impose_ your beliefs on
others, and to punish people that don't believe as you do.  That's
what certain governments that people on the list are concerned about
do.  People don't respond well when forced.  All you will do is
alienate them.

I suggest you offer an incentive for signature use rather than a
penalty for non-use.  For example, the "Quarterly Cookie Quota" (QCQ),
a pledge to send a package of cookies (good ones, too) to a signer
picked at random.  This will cost you $100 a year, less than the
time/$ cost of modifying the mail list software.

Bottom line: Use Carrots, not Sticks.  Using sticks is counterproductive,
especially when you try and use them on ornery jerks like the membership
of this list (humble correspondent included in that characterization).

I support your signature proposal in either iteration.  Don't be swayed by
armchair cypherpunks whining about how they might be inconvenienced by such a
policy.  And I say these things even though I am myself not yet fully positioned
to sign my messages (though I'm close).

	John E. Kreznar		| Relations among people to be by
	jkreznar@ininx.com	| mutual consent, or not at all.