Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!ucsd!ames!ubvax!vsi1!altnet!edc
From: edc@ALTOS.COM (Eric Christensen)
Newsgroups: comp.mail.elm
Subject: Re: Whatever happened to "Elm - the MAILER" ??
Summary: Let us refer to RFC822....
Keywords: RFC822 Encryption
Message-ID: <560@altnet.ALTOS.COM>
Date: 6 Jul 88 16:54:35 GMT
References: <470@altnet.ALTOS.COM> <278@clout.Jhereg.MN.ORG> <485@altnet.ALTOS.COM> <10291@ncc.Nexus.CA> <1060@datapg.DataPg.MN.ORG> <520@a <23@n0atp.UUCP> <10305@ncc.Nexus.CA>
Reply-To: edc@altnet.UUCP (Eric Christensen)
Organization: Altos Computer Systems, San Jose, CA.
Lines: 93

In article <10305@ncc.Nexus.CA> libPW.a[crypt.o] writes:
>In article <23@n0atp.UUCP> barry@n0atp.UUCP (Barry S. Berg) writes:
>>   What I propose is to put a dummy local routine in.  IBM calls this a
>>   user exit on their mainframe software. The local definiation would
>>   overide the external definition, not a lot of code would be generated,
>>   and the system would allow the use of crypt(1) or a PD crypt if desired.
>>   The following would be a code sample.
>
>Doing this just brings us back to the situation where site admin A
>uses crypt version X, and site admin B uses crypt version Z. User@A
>is still bitching because his encrypted mail worked *too* *good*
>when it got to Recipient@B because noone at B can decipher the damn
>thing!

OK folks, there are some real problems with encrypted mail. I'm the first to
admit that. But there are some benefits too. As I stated earlier, I'm for
providing encryption hooks on a optional basis (actually, Dave told me this
afternoon that the crypt stuff is all ifdefed in his 2.01 version). Go ahead
and flame me, but finish reading the rest of this first! :-)

Now, the question is how do we deal with the optional encryption? I think that
embedding ANY routine into Elm itself is a mistake. I'm all for using standalone
programs for these nasty little tasks. I think we should provide one PD crypt
with the Elm sources, so everyone who uses Elm will have access to the same
routine, but they have the option of using their own if so desired.   

RFC 822 deals with this issue, and as such I believe that we should do it in
the same way. (We ARE trying to be fully RFC 822 compliant, are we not?)

The option field specification from RFC 822 looks like this:


         optional-field =
                     /  "Message-ID"        ":"   msg-id
                     /  "Resent-Message-ID" ":"   msg-id
                     /  "In-Reply-To"       ":"  *(phrase / msg-id)
                     /  "References"        ":"  *(phrase / msg-id)
                     /  "Keywords"          ":"  #phrase
                     /  "Subject"           ":"  *text
                     /  "Comments"          ":"  *text
LOOK!>>>>>           /  "Encrypted"         ":" 1#2word
                     /  extension-field              ; To be defined
                     /  user-defined-field           ; May be pre-empted


Ok? Now here's the explination of the Encrypted field:


         4.7.3.  ENCRYPTED

                 Sometimes,  data  encryption  is  used  to  increase  the
            privacy  of  message  contents.   If the body of a message has
            been encrypted, to keep its contents private, the  "Encrypted"
            field  can be used to note the fact and to indicate the nature
            of the encryption.  The first  parameter  indicates  the
            software  used  to  encrypt the body, and the second, optional
             is intended to  aid  the  recipient  in  selecting  the
            proper  decryption  key.   This  code word may be viewed as an
            index to a table of keys held by the recipient.

            Note:  Unfortunately, headers must contain envelope,  as  well
                   as  contents,  information.  Consequently, it is neces-
                   sary that they remain unencrypted, so that  mail  tran-
                   sport   services   may   access   them.   Since  names,
                   addresses, and "Subject"  field  contents  may  contain
                   sensitive  information,  this  requirement limits total
                   message privacy.

                 Names of encryption software are registered with the Net-
            work  Information Center, SRI International, Menlo Park, Cali-
            fornia.

So we have a specification, as well as a registry for the encryption software.
Is this so bad? Agreed, we're taking a little artistic licence with the
'encryption on, encyption off' feature, but I agree with Dave. That should 
probably stay.

Now you can flame me! I would like to reach some agreement on this issue fairly
soon. As it is, the 2.0 release will just have the crypt stuff ifdefed out. But
I would really like to agree on what to do with future releases. If we've got
to do it by vote, I'll accept that, but I hope that we don't have to resort to
voting on every design issue, enhancement, or modification that someone comes
up with. 

-- 
+-------------------------+--------------------------------------------------+
| Eric D. Christensen     | Email: edc@altnet.altos.com  (uunet!altnet!edc)  |
| Altos Computer Systems  +--------------------------------------------------+
| 399 West Trimble Road   |  Note: There are no spelling errors in this      |
| San Jose, Ca. 95131     |        message.... I just can't type!            |
+-------------------------+--------------------------------------------------+
| These views aren't Altos' - They're mine, all mine, and you can't have them|
+----------------------------------------------------------------------------+