What is needed for S/MIME remailer ?

The other day I was wondering what it would take to make an
anonymous remailer for an S/MIME client.  Implementing S/MIME from
scratch is a lot of work given the lack of a public domain
implementation, but it seems that a remailer could be built on top
of a commercial email product that supported S/MIME.  The question
is: What features should a commercial S/MIME email product have to
make it easy to support a remailer?  Are there a small set of
command line options that would greatly simplify a remailer
implementation?
                --Bob Baldwin

My understanding of S/MIME isn't excellent, so I figure there are
things I could be confused about which may make this a bit wrong..

I figure a command line S/MIME program which could easily be
integrated into a remailer wouldhave the following features:

A) limit on number of multiple concurrent procersses doing
decryption. Remailer spams have the bad effect of spwaning hundreds of
concurrent PGPs on the mailhost, bringing things to halt. Limiting
number of concurrent decryptions would help this problem.

B) A strong interaction with the UNIX shell, with the program
returning a return code based on whether or not the decryption
succeeded. (Remailers only do decryptions...) That way a remailer
could something like:

#!/bin/sh
if smime -f < incoming-message > /tmp/decrypted.$$
then
  # Process /tmp/decrypted
fi
rm incoming-message
rm /tmp/decrypted.$$

	The option would also be a very low-cruft-output -- there
would be none of that PGP v2.6.2 stuff that PGP sends out. Just the
decrypted output and if the message cant be decrypted, nothing gets
output. (Maybe a -q option for that..)

	I think the smime should be easily plugged into premail as
well, but I don't know premail to know what would be necessary for
that. I suspect Raph would have some input on that matter.


> 
>         The other day I was wondering what it would take to make an
> anonymous remailer for an S/MIME client.  Implementing S/MIME from
> scratch is a lot of work given the lack of a public domain
> implementation, but it seems that a remailer could be built on top
> of a commercial email product that supported S/MIME.  The question
> is: What features should a commercial S/MIME email product have to
> make it easy to support a remailer?  Are there a small set of
> command line options that would greatly simplify a remailer
> implementation?
>                 --Bob Baldwin
> 


-- 
sameer						Voice:   510-601-9777
Community ConneXion				FAX:	 510-601-9734
The Internet Privacy Provider			Dialin:  510-658-6376
http://www.c2.org (or login as "guest")			sameer@c2.org

sameer writes, among other things:

> A) limit on number of multiple concurrent procersses doing
> decryption. Remailer spams have the bad effect of spwaning hundreds of
> concurrent PGPs on the mailhost, bringing things to halt. Limiting
> number of concurrent decryptions would help this problem.

Agreed.

> B) A strong interaction with the UNIX shell, with the program
> returning a return code based on whether or not the decryption
> succeeded. (Remailers only do decryptions...) That way a remailer
> could something like:

We very much need a command line interface to S/MIME, to use in remailers
and also for other kinds of testing/hacking. I hope one is forthcoming
soon.

> 	I think the smime should be easily plugged into premail as
> well, but I don't know premail to know what would be necessary for
> that. I suspect Raph would have some input on that matter.

Raph does indeed have some input on the matter. I am currently rewriting
premail from the ground up, and am about 700 lines into it. One specific
design goal was the support of other types of encryption, including
Mixmaster and MOSS in the first release, and hopefully others as well.
Basically, I'm waiting on a command line S/MIME implementation as
described above, most hopefully as free software.

In any case, the new premail is _much_ more modular, so plugging in
experimental email stuff should be pretty straightforward.

Raph

baldwin , Robert W. Baldwin wrote:
> 
>         The other day I was wondering what it would take to make an
> anonymous remailer for an S/MIME client.  Implementing S/MIME from
> scratch is a lot of work given the lack of a public domain
> implementation, but it seems that a remailer could be built on top
> of a commercial email product that supported S/MIME.  The question
> is: What features should a commercial S/MIME email product have to
> make it easy to support a remailer?  Are there a small set of
> command line options that would greatly simplify a remailer
> implementation?

  S/MIME is mostly PKCS#7.  Eric Young is doing an implementation
of PKCS#7 for his SSLEAY package.  It seems like a good place
to start...

	--Jeff

-- 
Jeff Weinstein - Electronic Munitions Specialist
Netscape Communication Corporation
jsw@netscape.com - http://home.netscape.com/people/jsw
Any opinions expressed above are mine.