Hi Mohit,
Thank you for the review. Responses below.
On 3/18/24 2:11 AM, Mohit Sethi via
Datatracker wrote:
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.
Its possible that client and servers you do integrity checking per RFC 9530, but as you suggest, that it something that some be addresses in the JMAP core spec.
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.
I'm guessing that this is an issue with the tooling that we can
fix during AUTH48.
-- Kenneth Murchison Senior Software Developer Fastmail US LLC
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
