Using GPG to create virtual email addresses

[Jacob Anawalt]

Greetings,

I am interested in using GPG to create virtual email addresses such that:

* The address is unique for every sender/reciever pair.
* The address will change if the sender or reciever changes keys.
* The admin doesn't have to do anything for a new valid virtual address 
to work.
* The reciever can have different processing rules based on the trust 
the reciever has in the sender.
* The origional encoded data is not sensitive or directly used.
* The system should be easy to use (transparent if possible) in the MUA 
software.
* The system should enable the MTA to make SMTP time decisions decisions 
to accept or reject delivery.
* The virtual address should be hard for a 3rd party to create.

Example:

Sender jacob@my_other_mailserver.com sends to 
jacob+gpgonly@cachevalley.com, but the address is changed to 
jacob+JPO/F?WE/ASDIOD@cachevalley.com before it is sent from the MUA to 
the sending MTA.

The destination SMTP server (cachevalley.com) does a lookup after the 
MAIL FROM and RCPT TO commands verifying that jacob+JPO/F?WE/ASDIOD is a 
valid address for jacob-gpgonly@cachevalley.com and it was sent from and 
encoded by jacob@my_other_mailserver.com. Direct mails to 
jacob-gpgonly@cachevalley.com may or may not be accepted based on other 
policies.

The receiving mail server doesn't need to have it's recipient's private 
key. It is enough for it to decode using the sender's public key and 
then verify that the result was encoded by the recipient's public key.



In many aspects GPG seemes like a good fit. GPG plugins are available to 
many MUA platforms. The security is enhanced by a trust metric. Users of 
GPG are able to revoke old public keys and submit new ones at any time, 
the other party just needs to have their software fetch the latest 
public key before processing the data.

The first obstacle to me seems to be the size of the encoded data. 
RFC2821, section 4.5.3.1 says that the maximum lenght of local-part is 
64 characters. The local-part after encryption needs to be RFC email 
envelope  compliant.

My question to this group is this:

Is there a method of encoding available to GPG such that it could make 
the local-part restrictions target and still have enough data to 
validate that encoding was created using a combination of the sender's 
private key and the receiver's public key (possibly by having been 
encoded twice, in that order).

Perhaps I don't even need the jacob+ part of the local-part. If that was 
not necessary then all 64 characters would be available to GPG. If the 
identity is necessary, maybe it should be <recipient gpg id>+<encrypted 
username> for better length control.

As I mentioned in the requirements section, the encrypted 'data' isn't 
realy used, except as a target of the encryption. Maybe there is some 
'light signature' option that would work better. I think it would be 
best if either party could change their current public key and have that 
change reflected in all future virtual addresses until the next change, 
and yet have the new address recognized shortly after the change is made.

If GPG cannot and will not accommodate this, is there some encoding 
scheme out there that does?

MUA - Mail User Agent (Mutt, Pine, Outlook)
MTA - Mail Transport Agent (Sendmail, Postfix, Exim)
--
Jacob