Subject: Re: [Jmap] [JMAP] SMIME Attachments (was: Re: S/MIME for JMAP)

From: vaibhav singh <[email-masked]>
Date: Sun, 29 Oct 2017 13:03:28 +0530

>
>    1. Re: [JMAP] SMIME Attachments (was: Re:  S/MIME for JMAP)
>       (Bron Gondwana)
>
>
> ---------- Forwarded message ----------
> From: Bron Gondwana <[email-masked]>
> To: [email-masked]
> Cc:
> Bcc:
> Date: Thu, 26 Oct 2017 09:04:40 +1100
> Subject: Re: [Jmap] [JMAP] SMIME Attachments (was: Re: S/MIME for JMAP)
> If you want to use a JMAP server to pass opaque blobs, that works fine.
> Obviously things like hasAttachment aren't going to work, because the
> opaque blob doesn't have an attachment.  The mail inside may have an
> attachment, but the JMAP server doesn't know that.
>
> Since the same issue exists with IMAP, it sounds like maybe what you're
> suggesting is an IANA registration of a keyword like
> $HasEncryptedAttachment, which would allow multiple MUAs to share that
> metadata.  Of course the server couldn't add it, so it would only be
> present at the time the first MUA-with-keys connected and downloaded the
> message to evaluate its contents.
>

Yes, I can start the process for requesting " $HasEncryptedAttachment "be
registered by IANA, in case nobody sees an issue with it.

-Vaibhav

>
> If you're a server handling encrypted blobs, you can't do much other than
> store and forward.  Most of the complexity of JMAP is around making the
> server smarter and clients easier to write.  The place for JMAP in the case
> you're talking about would be as a local protocol between a secure crypto
> store and a client within your device - you could run an embedded JMAP
> server which did the crypto for you and more easily choose between multiple
> client implementations.
>
> There's still some value in JMAP push, even if the server can't inspect
> the message it can still push out-of-band that something is new on the
> server and the client needs to resync.
>
> Bron.
>

>
> On Wed, 25 Oct 2017, at 22:16, vaibhav singh wrote:
>
> Hi,
>
> Sorry If I sound like a broken record; I had asked this question before as
> well, maybe I wasn't specific enough, but I still feel that integrating
> S/MIME in JMAP will be a pain.
>
> The first pain point is with respect to all the metadata you are adding
> for messages; if I were to implement an S/MIME extension for JMAP I would
> probably encrypt and sign (at least some) of the metadata as well. Things
> could break at this point (sorry for sounding a bit vague; I still haven't
> gotten around to going through JMAP spec, but I am pretty sure people here
> would see the point I am trying to make here.)
>
> The second pain point (more appropriate with the subject line) is with
> attachments being present in the encrypted mime. Maybe a flag needs to be
> added by the MUA to an encrypted mail, so that server may not have to
> decrypt the mime to get to know that an attachment is present within the
> mime. This, now that I put thoughts into words, is more an optimization
> than anything else, but I would still like to have your views on this.
>
> I would again like to mention that I love what you are doing, I still
> consider myself a newbie to IETF in general, and JMAP is probably the
> working group I am most interested in. I will go through the whole spec the
> first chance I get.
>
> --
> Regards,
> Vaibhav
> *_______________________________________________*
> Jmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jmap
>
>
> --
>   Bron Gondwana, CEO, FastMail Pty Ltd
>   [email-masked]
>
>
>
> _______________________________________________
> Jmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jmap
>
>

-- 

Regards,
Vaibhav Singh