[imp] PGP and S/MIME

[Cliff Green]

On Wed, 8 May 2002, Arkadiusz Goralski wrote:

AG> On Tuesday 07 May 2002 21:53, Andreas Dahlén wrote:
AG> > I've been looking at implementing S/MIME in IMP.
[munch]

AG> > * Use of external program or internal function calls.
[munch]
AG> I think it should be done (if possible) on the client-side. IMP should
AG> only do  it's job: create proper messages for sendmail or other MTA.

Hmm.  IMP is useful for when you only have a browser, and it's not your
computer;  therefore, you don't have your keys locally.  If you do (let's
say you have a token or smartcard), then you may not be able to install
the s/w to use it (e.g., my Litronics card needs a reader and software
which I cannot rely on finding on someone else's computer;  and now that
my portable is fried, it's useless).  For those reasons alone, it's
helpful for IMP to be able to do everything on the server side.
Fortunately, if building a message completely in IMP is onerous, openssl
can be used to create the full message, given the correct parameters.

Nevertheless, it's also valuable to require two-factor authentication with
a token or card.  How are you doing this?  I'm not saying that one product
should be all things for all users, but it certainly could be possible to
run two versions of IMP (okay, one version configured two ways) - one for
roamers and one for users with tokens (e.g., a corporate site may require
tokens, while a university might not).

AG> > * Storing of Certificates
[munch]
AG>
AG> This seems to be the only solution, but we've managed to actually sign
AG> the message within the web browser and put the signed message back into
AG> the HTML form for further operations (sending etc.). You can select
AG> with which key you want to sign the message from the combo box.

Nice.  Is this a CGI app?  PHP?  Something local, installed on your
computers?  Java?

AG> Additionally you can sign the message with using your private key
AG> stored on a smart card or other hardware modules.
AG>
AG> And the best part is, that all is done on the client-side, so you
AG> don't have to build PHP with openssl modules or play with S/MIME.
AG> All you have to do is to acctually send the message.
AG>
AG> BUT if you want to read the signed/encrypted message, then IMP must
AG> support reading such mails.

Again, you're back to requiring openssl, one way or another.

AG> > * Root Certificates
AG> > The root certificates are needed to verify signatures. How should
AG> > they be stored? My suggestion is to use ca-bundle.crt that comes
AG> > with mod_ssl.
AG>
AG> RootCA ID's should also stay on the client-side (for MS IE -> Windows
AG> registry or Netscaper cert{5,7}.db) and the process of deciding
AG> whether a particular RootCA is trusted or not should also be performed
AG> on the client-side.

I don't know - it seems to me that it's easier to manage private hierarchy
signing keys if they're centrally maintained (yes, it's not difficult to
provide them for your users, just tedious).  Put them in one place and
they're immediately useful for IMP users, without having to download and
trust them.

[munch]
AG> Acctually we're willing to implement client-side message
AG> signing/encrypting in IMP, but only for 2 browsers:
AG>
AG> 1. MS Internet Explorer >=4 (via native capicom.dll)
AG> 2. Netscape (via Netscape Form SIgning Functions) - not yet tested,
AG> but we're working on it :)

We've used crypto.signText() successfully for signing data in Communicator
(4.75+);  it generates a pkcs7 blob which could then be either attached to
a message or processed by openssl on the server.  The same goes for
XSigner (part of Xetex' XSigner ActiveX control) for IE (we require 5.0+).

We're not using either of those for s/mime, though - just for workflow
apps (signing forms, etc.).  Figuring out how to harden IMP seemed to be a
better alternative;  our requirement is for a "roaming solution" for users
who either don't have their own computers, or who don't stay at and use
only one computer.  Unfortunately, the only roaming solutions we've seen
so far don't meet our needs (i.e., one is specific to one browser, and the
other doesn't allow for signing).

c
-- 
Clifford Green               Internet -  green@umdnj.edu
Academic Computing Services     voice -     732-235-5250
UMDNJ-IST                         fax -     732-235-5252