On Tue, Jul 08, 2003 at 11:36:32PM -0400, Kee Hinckley wrote
PGP (and GPG) already exist, and have been in use long enough that
submarine-patents are unlikely (never say "never"). Front-ends for
signing exist in Windows, even. No need to re-invent the wheel.
You've lost me. What does this have to do with consent token's not
degenerating to passwords, or with URL schemes for whitelisting?
The best response is an example. Here goes. In both instances, we'll
assume extensions to SMTP. ("EHLO").
Password approach
=================
ASRG puts up an XML structure on its signup page. The necessary
elements are something like
- TOKEN = OOGA_BOOGA
Subscribing consists clicking on a URL. This will pop up a dialog in
the users's browser that...
1) Submits the the user's email address to the mailing list
2) Saves the XML token data to the user's account on his ISP.
Spammer notices that this group is almost exclusively male, and a
p****-enlargement ad will be "100% targetted". Spammer sends a spam
containing the additional SMTP command...
TOKN: OOGA_BOOGA
Recipient's ISP checks their database, sees that this client has listed
OOGA_BOOGA as a valid consent token, and lets the spam through... oops.
Key-based approach (similar to ssh)
==================
ASRG puts up an XML structure on its signup page. The necessary
elements are something like
- TOKEN = blah_blah_blah, where blah_blah_blah is either public key or
a URL pointing to a public key (DSA/RSA/whatever).
Subscribing consists clicking on a URL. This will pop up a dialog in
the users's browser that...
1) Submits the the user's email address to the mailing list
2) Saves the XML token data to the user's account on his ISP.
The extended SMTP transaction would include the following...
(sender) "TOKN: blah_blah_blah"
The recipient's ISP consults its database. If that recipient doesn't
have that token in its list, reject email. If recipient has token, the
ISP's MTA will
- calculate a short random character string
- encrypt it using the public key passed or referenced in TOKN:
- send back to sender...
CHLG: sdfdjkssdkjhdui89348gobbledygook <encrypted string>
The sender responds by transmitting back in cleartext, a decrypted
version of the CHLG: string. If it's successful, the email is accepted.
Advantages are similar to ssh
- Any sender can generate their own keys for their own mailings; no
central signing authority needed (Sorry Verisign<g>)
- People can listen in to the exchange with a packet-sniffer, and
nobody this side of the NSA will be able to forge the token. The
sender requires the private key corresponding to the public key in
order to be able to successfully respond to CHLG:
- Separate keys for separate lists are possible, for fine-grained
control
- The same private key can be shared amongst multiple senders if
required
- Listing/revoking is handled by client on their ISP.
- No bounces to innocent 3rd parties. An SMTP-time 5XX reject is
issued instead
--
Walter Dnes <waltdnes(_at_)waltdnes(_dot_)org>
Email users are divided into two classes;
1) Those who have effective spam-blocking
2) Those who wish they did
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg