On Mon, 1 Jul 2002 11:30:41 -0400 (Eastern Daylight Time) "Eric S. Johansson"
<[EMAIL PROTECTED]> wrote:
> On Mon, 1 Jul 2002 10:45:44 -0400 (EDT) Richard Welty
> <[EMAIL PROTECTED]> wrote:
> RW> the complexity is really all in the certificate handling. there's no
> RW> certainty when a message arrives that is signed and/or encrypted
> that you
> RW> have the certificates in hand needed to deal with it. if you have
> them,
> RW> then the rest of the work isn't so bad.
> for me, this is the primary reason why s/mime is evil. As soon as you
> introduce certificates, this means you have to have a certificate
> authority. Self signed certificates don't even have a web of trust to
> fall back on.
well, yes and no. when i was at VPNet (an IPSec appliance vendor, now a
part of Avaya), we acted as our own authority, and simply supplied
customers with our certificates. for a company, or a small group of
companies, or a group of developers, rolling a small agreed upon CA isn't a
killer deal. OpenSSL has the tools to do this in the small (and i would
agree that it doesn't scale terribly well at all.)
> RW> good UI decisions here will determine whether or not S/MIME support
> would
> RW> be useful or ignored.
> I wholeheartedly agree. And I'll also add that the best UI for
> encryption is no UI. Encryption and decryption should happen
> automatically, invisibly, without any user intervention necessary.
i agree with this as an ultimate objective. would that the current Public
Key Infrastructure were up to such an ideal.
with reference to the earlier proposal about allowing email to be stored
encyrpted vs non-encrypted, be aware that there are numerous issues when
PKI becomes involved. specifically, certs have expirations (vendors like
verisign make them one year out, as that seems to be the best marketing
tradeoff for making money on renewals. when i manufacture certs, i
generally make the expirations 10 years out). also, there are nasty things
called CRLs lurking in the background (although CRLs are rarely
agressively implemented because they're an absolute bastard to get right).
an expiration or a revocation could render a message stored in encrypted
form inaccessible if the design design doesn't take the possibility into
account.
you end up needing, i think, to store mail encrypted when the certificates
aren't available, to convert at the earliest occasion possible, and to
provide options on cert handling to cover the CRL and expiration issues. i
think that it's doable, but it needs to be thought out carefully before any
code gets slapped won.
in Un*x the cert handling is OpenSSL is commonly used by default; in
Windoze, older versions have it integrated into Outlook and newer ones (w2K
and XP based) move it into a central certificate authority. one way to
skate around the issue is to lean on what exists in the base OS. the
downside here is that with OpenSSL there's no GUI that i've seen (i've not
gone looking, admittedly), and in Windoze, you're stuck with whatever M$
supports in that particular version (which usually changes in seemingly
arbitrary ways from version to version.)
another downside to depending on the base OS is that if you find you need
to take manual steps to put a cert in place, you'll be in the MUA and will
be annoyed at stepping out to deal with the cert.
richard
--
Richard Welty [EMAIL PROTECTED]
Averill Park Networking 518-573-7592
Unix, Linux, IP Network Engineering, Security
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Mahogany-Users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mahogany-users
