Re: [imapext] General Request for Assignment (imap-keywords) (was: [JMAP] SMIME Attachments)

Cyrus Daboo <cyrus@daboo.name> Tue, 14 November 2017 14:58 UTC

Return-Path: <cyrus@daboo.name>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9A2124C27 for <imapext@ietfa.amsl.com>; Tue, 14 Nov 2017 06:58:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKUJn43dI7_X for <imapext@ietfa.amsl.com>; Tue, 14 Nov 2017 06:58:46 -0800 (PST)
Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA7D112426E for <imapext@ietf.org>; Tue, 14 Nov 2017 06:58:46 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 01DF782010E4; Tue, 14 Nov 2017 09:58:46 -0500 (EST)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0iVM5J8Kzlp; Tue, 14 Nov 2017 09:58:45 -0500 (EST)
Received: from caldav.corp.apple.com (unknown [17.44.178.52]) by daboo.name (Postfix) with ESMTPSA id A89C082010D5; Tue, 14 Nov 2017 09:58:44 -0500 (EST)
Date: Tue, 14 Nov 2017 09:58:42 -0500
From: Cyrus Daboo <cyrus@daboo.name>
To: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>, imapext@ietf.org
Message-ID: <5E5BABB0AC20B6710541DF4D@caldav.corp.apple.com>
In-Reply-To: <914700fa-473e-422a-9bda-d22c9afabba5@gulbrandsen.priv.no>
References: <CACZ1GipM4+91KL00_YDcUHSF0eVnjh8vZAddbk869O4J1w9ZfA@mail.gmail.com> <c2f0b35e-1925-4769-9a22-c6663db1eb53@gulbrandsen.priv.no> <1510668418.767816.1172078600.47C2F0F2@webmail.messagingengine.com> <914700fa-473e-422a-9bda-d22c9afabba5@gulbrandsen.priv.no>
X-Mailer: Mulberry/4.1.0b1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size="1376"
Archived-At: <https://mailarchive.ietf.org/arch/msg/imapext/H2SWpdgxGnyixFzFha_648ZaRmI>
Subject: Re: [imapext] General Request for Assignment (imap-keywords) (was: [JMAP] SMIME Attachments)
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Nov 2017 14:58:50 -0000

Hi Arnt,

--On November 14, 2017 at 2:25:06 PM +0000 Arnt Gulbrandsen 
<arnt@gulbrandsen.priv.no> wrote:

>> Anyway, I don't think the whole way this would work has been
>> well thought out yet.
>
> AOL. It would seem to serve the case where the user uses two clients,
> both of which display whether a message has an attachment and neither of
> which displays any other information from inside the blob. In particular,
> neither can display an excerpt of the text, or any information about the
> kind of attachment.
>

I think a much more useful option would be for the first client to decrypt 
the blob and generate an IMAP-like BODYSTRUCTURE which it then encrypts to 
the user's public key and uploads as metadata attached to the original 
message. Then other clients which have the private key can grab the 
metadata and decrypt it to get the full structure of the encrypted blob. 
That way the clients get to learn a lot more about the message than the 
mere fact it contains an attachment.

Note, that it might also be useful to send the encrypted BODYSTRUCTURE data 
as a separate part/header in the encrypted message. That way recipients 
would also gain the benefit of being able to quickly determine what the 
message contains. Of course that additional data does potentially leak some 
information about the message, but that might be acceptable.

-- 
Cyrus Daboo