Re: [Last-Call] Secdir last call review of draft-ietf-jmap-contacts-06

[Neil Jenkins <neilj=40fastmailteam.com@xxxxxxxxxxxxxx>]

Hi Shivan,

Thank you for your review. I have published an updated draft addressing your comments, details below.

Section 1.4

This section says "This document defines two additional capability URIs." but

AFAICT it's only one i.e. urn:ietf:params:jmap:contacts

Fixed.

Section 2

Why does description property not have any restrictions unlike the name

property?

The name property has a length restriction, as it's intended as a short-ish name for display. The description property does not have a length restriction (servers may enforce sanity limits, as for any property of course).

In general, it's a bit confusing which properties are mandatory and which are

optional: sometimes it's pretty obvious (id and name), and sometimes it's not

(sortOrder). I would highly recommend explicitly labelling all properties as

either mandatory (and then defining what the possible values are), or optional

(similar, but also with a sensible default).

The current presentation follows the conventions of existing JMAP documents. As per RFC8620, Section 5.3, the "object type definition may define default values for properties.  Any such property may be omitted by the client."

As per RFC8620, Section 1.1, the "the client MUST NOT send [a server-set] property when creating a new object of this type."

Looks like Principal is missing a reference to

https://datatracker.ietf.org/doc/html/draft-ietf-jmap-sharing-06.

Thanks, I've added a reference.

mayDelete property in AddressBookRights is confusing, since I first thought it

means the ability to delete ContactCards since that's what mayRead and mayWrite

mention.

I see how you interpreted it like this, but I'm going to stick with "mayDelete" as it's consistent with what we did in RFC8621 for mailboxes, and if you read the description it's clear (as you found).

Section 5

The Security Considerations section needs to address the fact that a user query

which uses filtering/sorting is basically untrusted input and recommend how to

sanitize and treat the input. It should at the very least point to RFC 8620

security guidance around parsing JSON input.

As this document is just defining a few data types within the JMAP protocol, all of RFC8620's security considerations apply, as already noted in the document. I'm not sure what you consider a new security consideration around filtering/sorting with this document?

Cheers,

Neil.

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