At 12:27 PM 5/12/2003 -0400, you wrote:
>On Mon, 12 May 2003 09:06:10 EDT, "Hiler, John" <[log in to unmask]>  said:
>> I totally agree with DCP, a "no brainer".
>
>Although you may *THINK* public-key auth is a "no brainer", it's not as easy
>as it looks (as years of experience dealing with security and crypto have
>taught me):

I never thought it would be easy -- it's especially difficult to provide generalized support as LISTSERV would need. We are most of the way through working out our own solution.

>3) You need end-user client support - basically, if it isn't either an
>S/MIME signature or a PGP signature, you will be stuck hand-rolling a
>plugin for the mail program to do the signatures for you.  And even if
>it *is* using S/MIME or PGP, you still have to walk the user through the
>process of downloading and installing the plugin, generating a key pair,
>explaining passphrases, and all the rest of it.

We will be using (as of right now -- it's in the hands of the coders) OpenPGP for signing from within an application. Email received for these specific lists will first go through a Perl script that will authenticate the message. If authentic and unique (never been seen before), it will strip the signage and propagate to the list via LISTSERV. If not, it will simply drop the message. The only way to get mail to the list will be via this script (called from Sendmail). Each list will have its own set of keys. In addition, the local server will keep a permanent track of all messages to ensure that each can only be sent once no matter what happens to the list dupe detection.

This is not a solution that would work for LISTSERV as a product, but it will do for us. It is relatively easy for us to do because the application is very standard within our organization and their is fairly strong centralized control of the code.

>4) You need to come up with a key management scheme - how do people get
>their public keys to Listserv so they can be authenticated?

We will issue a key file for each court that wants to use the system. Again -- not something that L-Soft would likely do, but useful in this case.

>5) The original poster needs to re-evaluate what he's trying to do:
>
>There's absolutely *NOTHING* stopping him from posting a PGP-encrypted
>sensitive information to a list *NOW*.

True -- but the advantage we are seeking is not end to end authentication, but originator to LISTSERV authentication.

>If it's that sensitive, it needs to be end-to-end encrypted, not "use crypto to authenticate it's from
>person/process XYZ" - that's just security through obscurity.  After all, interception of SMTP traffic is more likely *OUTBOUND*, just because only one copy came in, and hundreds may be leaving. ;)

Only one will come in signed.... they will leave unsigned. It's of no concern that the messages are on the list in signed format, only that we can trust that the messages come from the originating system and are unique. The first implementation will be for public announcements. It may be useful to encrypt submissions that are content or time sensitive -- but what we are looking for here is an immediate disbursement of information upon receipt. It's public information once the originating system releases it.

>No matter *WHAT* public-key system you're using, doing it via an automated system is a can of worms, because you *HAVE* to have the private key around so you can sign/encrypt.

True -- but if and when these systems are hacked, then we have other more pressing problems that an announce list. :-\

>Even after all that, I still agree it *would* be pretty cool if Listserv allowed PGP signatures as per RFC3156. ;)

That would be nice, too.

-- DCP