From roessler@does-not-exist.org Fri Feb 2 13:52:35 2001 Date: Fri, 2 Feb 2001 13:52:04 +0100 From: Thomas Roessler To: Mike Schiraldi , Jason Pyeron Subject: Re: [secure-mua] inter-app string format On 2001-02-01 11:39:23 -0500, Mike Schiraldi wrote: > MUA gets message from foo@bar.com. It has a Content-Type of > multipart/encrypted; protocol=application/pgp-encrypted. It runs > "usmt --show-me-all-the-keys-for foo@bar.com" usmt says: > > | Version: usmt 1.0.0 > | CommandLine: --show-me-all-the-keys-for foo@bar.com This doesn't make any sense. After all, the message will be decrypted with one of the users' private keys. The selection of this key won't be any of the MUA's business, normally. (Except in the case that you integrate asking for pass phrases with the MUA.) On 2001-02-01 17:21:01 -0500, Jason Pyeron wrote: > 1 i want to get a very clear set of requirements from mutt. OK, I'll try to summarize what functions we need. -> decrypt text. This should take a stream of data (application/octet-stream), apply the appropriate private key, and return the decrypted data through another stream. Additional information to be supplied by the mailer by whatever way: - possibly a pass phrase - possibly a content-type - possibly information from the first part of a multipart/encrypted (BUT: Is this used at all with S/MIME? If not, we can safely ignore it.) Additional information to be returned by the back-end: - status of decryption - status of signature verification in the case of combined signature/encryption envelope with PGP/MIME - possibly human-readable information to be displayed by the MUA. Note that this can just as well be used for traditional PGP decryption, and possibly even to verify traditional "cleartext" PGP signatures. -> verify signature. This should take two streams of data (signed material, detached signature) and verify whether the detached signature matches the signed material. The signed material can be assumed to be in textual form, the signature can't be assumed to be this. Additional information to be supplied by the mailer: - micalg parameter Additional information to be returned by the back-end: - status of signature verification - possibly human-readable information to be displayed by the MUA. -> encrypt text. One stream of data comes in, another stream goes out. Additional information to be supplied by the mailer: - list of unique key IDs which should be able to read the encrypted message. Additional information to be returned by the back-end: none. -> sign text. Signed material goes in, signature goes out. Additional information to be supplied by the mailer: - unique ID of key which should be used to sign this message. Additional information to be returned by the back-end: - MIC algorithm used. -> possibly: sign and encrypt. Basically, just combine the above two functions. Used for PGP's sign-and-encrypt shortcut. Output data looks like encrypted material. -> get list of keys. Output data should be a list of key descriptions (like what we discussed before). Additional information to be supplied by the mailer: - some set of hints which are to be matched against the strings human-readable IDs. For instance, an e-mail address, an addresse's local part, fragments of a name, etc. Of course, the mailer could also just give the e-mail address and the real name, and leave the details to the back-end. However, this would imply that the backend would need an RFC822 address parser, which is a complex animal. (Mutt has one, feel free to grab it. It's under the GPL.) - What key ring to access. While sharing a back-end between S/MIME and PGP is nice, we most likely shouldn't mix the two in the same message. (Exception: Signatures. But that can be solved in the MUA.) -> possibly: extract a key. Output data should be a public key (certificate) in transfer format. -> possibly: import keys. Input data should be a stream of data in a format common for the "crypto world" it's destined for, e.g., ASCII armored PGP key, certificate for S/MIME world, etc. For S/MIME, this would most likely be integrated with "verify signature". -> possibly: verify key. The MUA would supply a unique key ID, the back-end should return human-readable information which can help the user to decide whether or not he wants to use this key. Something like "pgp -kvc". > specifically pseudo code on how you would like an api to work. I'll just give you the API we currently use for PGP. ;-) On 2001-02-01 17:29:28 -0500, Mike Schiraldi wrote: > Yeah, i'd like to move to SourceForge. Not really because of IP > reasons, but mostly because eGroups munges email addresses and > tacks on ads for Yahoo. Go ahead. Or should I just set up a mailman list on some private list server? On 2001-02-01 17:48:31 -0500, Mike Schiraldi wrote: > Thomas: In particular, Jason and i have been discussing whether > or not usmt should have the ability to scan a message, look at > the Content-Types, and determine what actions to take. We were > hoping you might be able to provide some wisdom. This would amount to implement the /MIME part of PGP/MIME and S/MIME. I'd prefer usmt to provide a unified interface for the PGP and S parts of the two. ,-) > I currently think we should draw a line and say, "usmt will never > look at the message it's processing. It won't even provide you an > option of doing that." That means the MUA has to tell usmt what > to do: "PGP decrypt this." The MUA cannot say, "Here's a message; > figure out if it's encrypted. If it's encrypted, figure out how > it's encrypted. Then decrypt it." That's what I'd suggest. > The drawback is that the MUA must understand Content-Type and > have a .mailcap or something similar by which it associates > Content-Types with appropriate actions to take on them. Frankly, a MUA which isn't able to do this shouldn't be exepected to do PGP/MIME or S/MIME in the first place. On 2001-02-01 18:06:58 -0500, Jason Pyeron wrote: > The drawback is that the MUA must understand Content-Type and > have a .mailcap or something similar by which it associates > Content-Types with appropriate actions to take on them. With - at least - S/MIME and PGP/MIME, the MUA MUST have some understanding of these types anyways, because it has to replace a multipart/encrypted (or application/something) by whatever MIME tree comes out of the encrypted data. Of course, you could put this into a special mailcap flag, or something like that. Additionally, there must be some reasonable user interface for key selection, which, in most cases, would have to reside in the MUA for consistency purposes. Have a nice week-end, -- Thomas Roessler