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

[Bron Gondwana <[e-mail]>]

On Wed, 15 Nov 2017, at 01:58, Cyrus Daboo wrote:
> Hi Arnt,
> 
> --On November 14, 2017 at 2:25:06 PM +0000 Arnt Gulbrandsen
> <[e-mail]> 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.

The main value of any non-encrypted facts about the message (like a
keyword about the attachment state) is to allow server-side search.
I agree with Cyrus - the sender could easily attach the BODYSTRUCTURE as
a separate encrypted part, though again that leaks information about the
structure based on the size of the encrypted part - all sorts of side
channel/metadata stuff needs to be thought through, and different people
have different tradeoffs/risk profiles - but then most people don't want
to think that deeply about every message they send, so if you make it
too complex nobody will use it.
Regardless of what gets stored encrypted or who does it however, the
value of a keyword is search/sort.
I still remain unconvinced that the usecase is common enough that any
client would use it, particularly since the first client still needs to
download the message so it can set the flag.
Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [e-mail]