Hi Bron, Thank you for your reply.
Comments begin with SME.
On 11/10/22 7:08 AM, Bron Gondwana
wrote:
On Mon, Nov 7, 2022, at 00:19, Shawn Emery via Datatracker wrote:
Reviewer: Shawn Emery
Review result: Has Nits
Hi Shawn, thanks for your review!
This proposed standards draft specifies an extension to the JSON Meta
Application Protocol (JMAP). Specifically this draft defines an extension for
creating, identifying, and retrieving "blobs" of data without the need of
utilizing separate roundtrips.
The security considerations section does exist and refers to various ways to
mitigate against attacks related to unsupported data types, unauthorized access
control, blob existence leaks, mismatch between data type and data, and the
fragmentation of data to bypass scanner checks. I concur with the set of
possible attacks on this extension, though I do have one question on this
sentence:
The server SHOULD NOT reject data on the grounds that it is not a valid
specimen of the stated type.
Is there ever a case that one implementation accepts the data that does not
match the specified type and then another implementation assumes that the data
is that of the specified type? If this is the case then this could lead to
vulnerabilities while parsing said data.
The type information isn't stored with the blob, so - you only know the type if it's passed. The idea behind the blob store in JMAP is that it's just octets with no associated meaning.
I would be happy to change this to MUST NOT reject data.
SME: Hmm, if this is supposed to be a soft-fail in some contexts
then leaving it as SHOULD NOT is fine by me.
SME: That's OK, it was just a nit for readability.The security consideration section should also initially state something
similar to that of RFC 8621:
All security considerations of JMAP [RFC8620] apply to this
specification. Additional considerations specific to the data types
and functionality introduced by this document are described [below].
I will add this.
General Comments:
Thank you for the variety of examples, though it would have been easier to read
them if the request and response were in sequence rather than trying to
remember which response went to which request or by scrolling up and down a few
pages to correlate the two.
Unfortunately that's not possible with JMAP, since it's a batch protocol, and the examples are written as batches since that's how they would be used in practice.
SME: Ah, sounds reasonable.I'm not for sure I understand the purpose of the Blob/get:properties:digest
function. Won't the endpoints be able to do this over the datafield for
themselves?
The idea is that a client with a partial download of a blob is able to calculate the digest of the section it has, and ask the server to verify that it's not corrupted by calculating a digest over the same range.
Editorial Comments:
s/of of/of/
s/supportedDigestAlgorithms/supportedDigestAlgorithms:/
s/in future/in the future/
I believe the last of those is legitimate usage either with OR without the "the", but I'm happy to add it.
Have made these three edits.
All the changes from your review are in -16. I have left the content type checking as SHOULD NOT.
SME: Looks good, thanks!
Shawn.
--
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
