[Last-Call] Secdir last call review of draft-ietf-jmap-sieve-19

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Reviewer: Mohit Sethi
Review result: Ready

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last-call
comments.

This document defines an API for managing Sieve scripts on a server using the
JSON Meta Application Protocol (JMAP). Sieve scripts are used for filtering
email messages. It defines the following * A new JMAP data type called
"SieveScript" * Reserves a new URI urn:ietf:params:jmap:sieve for referring to
sieve script capability supported on the JMAP server * Two new JMAP error
codes: invalidSieve and sieveIsActive

The document seems ready. It was easy to read and understand. The security
considerations section simply points to security considerations of RFC 8620 and
RFC 5228.

One thing that I wondered while reading is how the integrity of the script blob
is ensured? How does the receiver verify the integrity of the binary script
content received? I guess JMAP is always expected to use TLS as the underlying
communication protocol and hence there is integrity during transit. I wonder if
there are any other means? I briefly read RFC 8620. It seems the blobId is
somehow derived from the blob content because of the following text: "If
identical binary content to an existing blob in the account is uploaded, the
existing blobId MAY be returned." But it is never explained how the blobId is
generated in the first place. It seems to be some sort of a hash which can
provide some way of integrity checking of binary data. Anyhow, there is nothing
to be fixed in this draft. Maybe something to consider for the original JMAP
RFC 8620.

One tiny nit:

Link in the the following text appears to be broken: "Script content must first
be uploaded as per Section 2.2". The xml source looks correct "Script content
must first be uploaded as per <xref target="content"/>" but the link takes to
me to the top of the page instead of section 2.2.


-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux