Hazards of encouraging forged dig sigs

[Eric Hughes]

   From: "L. McCarthy" <lmccarth at ducie.cs.umass.edu>

   I foresee a
   situation in which a large portion of the list traffic uses forged or
   meaningless signing-server-appended dig sigs. When I establish automatic
   signature validation for incoming mail here Real Soon Now, there will be 
   plenty of noise generated by all the `false' negatives in the data to make
   a mockery of the authentication process. 

Recall my comments on transaction failure in a different context last
week.  What is important there is what happens under failure, not
under success.

Sig checking requires an analysis of the pragmatics of failure,
i.e. what happens.  What seems abundantly clear, no matter what
actions are taken, is that it will be actions plural rather than
action singular.  The decision process to decide what happens is much
more significant architecturally that what actually does happen.  An
embedded action, i.e. a hardcoded policy, would be bad, and since sig
failure handling is a relatively unexplored area, one can do it right
the first time.

Assuming such a failure recovery decision process, the actions are
simple: ignore, flag, discard, bounce, get key, etc.  None are
particularly difficult; the decider is what is hard.  Now, assuming
both decider and actions, you can very simply ignore all sig failure
for cypherpunks.

   Encouraging cryptographically
   valid signatures was the first suggestion I'd seen in this entire debate
   which seemed to promise tangible benefits; 

Syntactic checking also encourages valid signatures, just not as
strongly.

   encouraging cryptographically
   invalid signatures is the first notion which appears to offer tangible
   detriment.

It's a problem that won't go away that the existence of bogus
signatures merely make the problem imminent and proximate.

Eric