Re: ADMIN: proposed new policy on the mailing list

[hughes@ah.com (Eric Hughes)]

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