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