Encrypted MLs

[Fred Lindberg]

On Tue, 28 Apr 1998 18:40:43 +0200, Werner Koch wrote:

Dear Werner:

>Better use something like this:
>
>    gpg --decrypt --verify <original | gpg --sign.... --keyfile... >storage

Yes!

>For this I have the --status-fd option which writes textual messages
>which are easy to parse; you can use two different fd for the
>decryption and the encryption stage.  if the program returns with an
>error, a grep tells you what's the real reason.

Great! I assume the relevant part to parse will stay constant over
versions.

>It's okay to pass the email address to gpg.

Good.

>It is possible to add more signatures to a message.

Yes. I was thinking of having it optional to retain the sender
signature with the message. gpg could do this as an option, or the
output could be such that it would be easy to use/discard it.

>What I have to do is to change the sequence of the packets, but that is
>trivial (but the output is not valid gpg message).

It would be ok to get the message after the keys. It will be written to
disk with the message alone kept in memory. No big advantage to put the
message first.

>So we need a way to specifiy that a key must be signed by xxxxx;
>this is reasonable because it avoids lengthly trust calculations. 

Or just have a special key server for the list, accept anything and
make sure that only the "good" keys are added to the db. Since we take
assume that local security is 100% this should be ok.

>Hmmm, very complicated to put this all into the OpenPGP standard.

See above. I think the key issue is piping parsable error messages, and
a raw format that can be disassembled. Ideally, no items specific to
this application should be needed. The ML software would take care of
base64-encoding, PGP headers, etc.


-Sincerely, Fred

(Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)