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

From: vaibhav singh <[email-masked]>
Date: Wed, 25 Oct 2017 16:46:14 +0530

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

---

From: Bron Gondwana <[email-masked]>
Date: Thu, 26 Oct 2017 09:04:40 +1100

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.
 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.)> 
> 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.> 
> 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]