[I'm not subscribed to openssl-dev, so please copy me on
eventual replies.]
Stephen, folks,
I hope I don't bother you by giving some comments about
OpenSSL's smime utility from a MUA maintainer's point of
view - I'm the person currently in charge of the
development of the mutt mail user agent (-> www.mutt.org).
Basically, smime(1) is a tool we have been waiting for for
quite some time now. I hope we can add S/MIME support to
mutt quite soon now. PGP/MIME has been there for quite
some time now (essentially from the beginning), so S/MIME
would be a logical extension. ;)
So, first of all, thanks for your efforts!
The first design problem I see with the smime tool is the
fact that it apparently tries to do most of the MIME
handling itself. From my point of view, I'd greatly
appreciate some mode which essentially looks like PGP's
detached signatures, and doesn't know anything about MIME:
Throw a text file with MIME headers at smime, and just get
the signature data back (maybe even unencoded - we do have
a base64 encoder after all ;-). Throw a text file plus a
signature at smime, and just get the decrypted text file
back. Throw a text file at smime, and get the encrypted
text file. That way, the MIME handling can be done
completely within the mail user agent (which should be
prepared to do this anyway).
Doing this would have the additional benefit of permitting
an easy implementation of multipart/mixed signatures in
the mail user agent, see draft-ietf-openpgp-multsig-00.txt
on the usual Internet-Draft repositories - the user agent
could just run a couple of back-ends (pgp, smime, some
moss implementation, ...) on the various signatures and
the first part of a multipart/signed body.
Certificate handling may be an additional problem, but
then again, this may be due to my lack of experience and
understanding with OpenSSL. I'd somehow suspect that,
using x509(1) and similar tools, it should be possible to
efficiently create a list of existing keys, key IDs (or
key file names, or whatever), associated e-mail addresses,
and the validity of that association (which is obviously
important when doing key selection).
The third point which makes me wonder a bit is the
handling of the user's private key, and passphrase. Unless
I'm mistaken here, the smime(1) tool essentially uses
DES_read_pw (sp?), which in turn opens /dev/tty for
reading. For the inclusion of the smime tool with mail
user agents, it would be practical to be able to pass the
user's pass phrase as the first line of stdin (or,
possibly, some other file descriptor which could be
specified as a command line parameter). That way, a mail
user agent could cache the user's pass phrase for some
time, and pass it safely to the smime crypto back-end.
Kind regards, and thanks for your efforts,
Thomas Roessler
--
http://www.guug.de/~roessler/
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
