No Subject

[nobody@shell.portal.com]

Since people are talking about new remailer features, can I suggest
another one - how about single-use (or limited use) anonymous return
addressess (ARAs) ? There are quite a few situations I can envisage where 
I might want to give an anonymous return address to someone that could
only be used a limited number of times, or for a limited period of
time (e.g. in the medium term, buying something over the network from a 
company with digicash, but not wanting to receive junk mail from them
afterwards).

How I'd see it working is this : You'd send a message to a remailer
requesting an anonymous address token, along with the email address
to send to, the number of uses you want and the time period (perhaps 
up to some maximum set by the operator of the remailer). In the future, 
you'd also send some digicash in payment for the token, the value based 
on the number of uses and time limit.

The remailer would then create an encrypted token containing an id
number and the address, either signed or with an attached random
number. The id, number of uses and expiry date would be stored in a
database, along with the random number if you were using that for
authentication. The remailer would then mail the token (probably
using an anonymous return address) to the requester. The database
shouldn't need to be very large if only details of the outstanding
tokens are stored.

BEGIN NOTES 
  I'm not sure whether it would be better to store the address in
  the token or in the database, but I suspect that storing it in
  the token is better since it avoids the possibility of anyone
  getting hold of a copy of the database and reading all the addresses
  stored in there. However, if it's in the token then if all keys of
  all remailers used are compromised, you can follow the entire chain
  even after the token is used up, whereas if it was deleted from the
  database the chain would be broken forever. Perhaps a mixture of 
  mechanisms in the remailers would be best. 

  Another option might be to keep the address completely seperate, so
  the token would merely indicate whether the message should be sent
  to the address specified in the ARA, not for a specific address that
  the token was requested for.
END NOTES

After the ARA had been sent to someone and they used it to reply to
the sender, the remailer would recognize the token, and decrypt it
to get the real address, database id and authentication. If the 
authentication was valid and the time/usage limit not exceeded, then it
would forward the message to the email address enclosed (which
presumably could be another ARA), otherwise it would just ignore the
message.

Obviously using only a single remailer would require you to trust the
operator to limit usage correctly, however chaining several limited
use addresses will solve any problems if one remailer is trustworthy.


Example:

Message to remailer might be something like (comments in {}, -- shows
begining and end of messages) :

--
Request-Token 5 {uses} 14 {days} ARA {or email address}

{ standard PGP-encrypted ARA goes in here }

Request-Token-End

::
Request-Remailing-To: remail@foo.com

{ARA to send token to via remail@foo.com goes here}
--

The remailer would create something like :

--
Limited-Use-Token: 00000001/F4870921 (ID/random authentication)

{ARA or Request-Remailing-To: goes here}
--

This would then be encrypted with the remailer's public key, attached to
the end of the original message (after the Request-Token line was stripped
off), then fed into the remailer as usual. The sender would create the ARA
using this token, and forward it to whoever they wanted to communicate 
with.

When a message using the ARA came back, it would be decrypted as usual, 
and if the token line was valid the database would be checked for 
timed expiry, updated to indicate another use, then if valid, after 
the token line was stripped off the message would be remailed as usual.

If noone else does this in the next few months then I may hack it into
a remailer once I have my own machine to run one off.