Subject: [Jmap] Blob draft updates - please have a look at -04 before the interim

From: "Bron Gondwana" <[email-masked]>
Date: Sat, 16 Oct 2021 23:09:02 +1100

Sorry for the two versions in quick succession!  I realised I hadn't put anything in security considerations about virus checking blobs created by `catenate` the same way you might check blobs injected via `upload`.
*
*
*I've just posted draft-ietf-jmap-blob-04, which resolves a bunch of issues:*
 * https://github.com/brong/draft-gondwana-jmap-blob/issues/1
   * using `typeNames` in the request and `matchedIds` in the response for lookup
 * https://github.com/brong/draft-gondwana-jmap-blob/issues/2
   * if `data:asText` is requested and the selected octet range is not valid utf-8, then we add an `isEncodingProblem: true` property like in RFC8621.
   * also, if the selected range can't be entirely satisfied (length past the end of the blob) we set an` isTruncated: true` property in the response.
 * https://github.com/brong/draft-gondwana-jmap-blob/issues/3
   * added a `maxCatenateItems` capability field (suggested minimum 64)
 * https://github.com/brong/draft-gondwana-jmap-blob/issues/4
   * added Security Considerations around scanning the resulting blobs created by Blob/set the same way you would scan uploads.
*Yet again, I'm asking for your reviews!*

This is all implemented in the Cyrus IMAP server at https://github.com/cyrusimap/cyrus-imapd/pull/3685 - which I'm planning to rebase and neaten up once we're happy with this draft, and ready to do a working group last call.

We'll talk about it at the interim meeting with CalConnect next week, and I'm probably going to ask Jim for a working group last call after that unless there are any changes that people still want!

Cheers,

Bron.

P.S. ... and yes, I probably WILL come back after this with yet another document or two for server-side-coding and server-side-digests, but that's different enough not to merge into this one!  

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 18 Oct 2021 21:01:24 +0100

Hi Bron,

On 16/10/2021 13:09, Bron Gondwana wrote:
> Sorry for the two versions in quick succession!  I realised I hadn't 
> put anything in security considerations about virus checking blobs 
> created by `catenate` the same way you might check blobs injected via 
> `upload`.
> *
> *
>     <https://github.com/brong/draft-gondwana-jmap-blob/issues/1>
>       o using |typeNames| in the request and |matchedIds| in the
>         response for lookup
>     <https://github.com/brong/draft-gondwana-jmap-blob/issues/2>
>       o if |data:asText| is requested and the selected octet range is
>         not valid utf-8, then we add an |isEncodingProblem: true|
>         property like in RFC8621.
>       o also, if the selected range can't be entirely satisfied
>         (length past the end of the blob) we set an|isTruncated: true|
>         property in the response.
>     <https://github.com/brong/draft-gondwana-jmap-blob/issues/3>
>       o added a |maxCatenateItems| capability field (suggested minimum 64)
>     <https://github.com/brong/draft-gondwana-jmap-blob/issues/4>
>       o added Security Considerations around scanning the resulting
>         blobs created by Blob/set the same way you would scan uploads.
>

I've checked recent changes and they look reasonable to me.

Best Regards,

Alexey*
*

>
> This is all implemented in the Cyrus IMAP server at 
> https://github.com/cyrusimap/cyrus-imapd/pull/3685 
> <https://github.com/cyrusimap/cyrus-imapd/pull/3685> - which I'm 
> planning to rebase and neaten up once we're happy with this draft, and 
> ready to do a working group last call.
>
> We'll talk about it at the interim meeting with CalConnect next week, 
> and I'm probably going to ask Jim for a working group last call after 
> that unless there are any changes that people still want!
>
> Cheers,
>
> Bron.
>
>
> P.S. ... and yes, I probably WILL come back after this with yet 
> another document or two for server-side-coding and 
> server-side-digests, but that's different enough not to merge into 
> this one!
>