IMAP4 Access Control List (ACL) Extension
draft-ietf-imapext-2086upd-08

[Ballot comment]
While this entire document concerns access and permissions, it seems to lack any text describing the protocol security requirements of a protocol that sets such permissions. Section 4 details what rights one must possess in order to modify ACLs, but I don't really see any text that describes the related threats concerning impersonation, replays, eavesdropping and so on in ACL creation. I have no doubt that mechanisms to address such threats exist in core IMAP (like SASL and STARTTLS), but it would be nice if this document explained why implementers should bother to use them.

[Ballot comment]
While this entire document concerns access and permissions, it seems to lack any text describing the protocol security requirements of a protocol that sets such permissions. Section 4 details what rights one must possess in order to modify ACLs, but I don't really see any text that describes the related threats concerning impersonation, replays, eavesdropping and so on in ACL creation. I have no doubt that mechanisms to address such threats exist in core IMAP (like SASL and STARTTLS), but it would be nice if this document explained why implementers should bother to use them.

[Ballot comment]
This document says that identifiers used as usernames for the login
and authenticate commands are reserved to correspond to those users.
However the authenticate command doesn't really take a username.  I'm
not sure what the right way of saying this in IMAP is, but in SASL it
would be the authorization identity.  But basically the text should be
clarified to make it consistent with how authenticate actually works.

[Ballot discuss]
This specification depends on SASLprep, which is defined in RFC 4013.
  The security considerations of RFC 4013 say:
  >
  > This profile is intended to prepare simple user name and password
  > strings for comparison or use in cryptographic functions (e.g.,
  > message digests).  The preparation algorithm was specifically
  > designed such that its output is canonical, and it is well-formed.
  > However, due to an anomaly [PR29] in the specification of Unicode
  > normalization, canonical equivalence is not guaranteed for a select
  > few character sequences.  These sequences, however, do not appear in
  > well-formed text.  This specification was published despite this
  > known technical problem.  It is expected that this specification will
  > be revised before further progression on the Standards Track (after
  > [Unicode] and/or [StringPrep] specifications have been updated to
  > address this problem).
  >
  The security considerations of this document need to address this point.
  How does this situation impact ACL processing?

Updated AD evaluation comments based on discussion with the WG:

- The -05 version of the document asked a question about whether or not this document updates RFC 3501.  The question was removed from -06.  I don't believe it does update 3501, but I'm open to other opinions.

- A Table of Contents is needed.  Other formatting errors found using the ID nits tool [1] should also be corrected.

- Section 3, 7th paragraph: "an ACL may include rights".  Is this "may" supposed to be in lower case letters?  I won't call out any more, but let's consider this an open question for any other 2119 keywords that appear in both upper and lower case letters.  Consistency is a good thing.

AD evaluation comments and questions:

- What does "Updates: <<3501?>>" mean in the first page headers?  Does this document update RFC 3501 or not?

- Please remove what looks like a reference to RFC 3501 ("IMAP4rev1") from the abstract, or maybe just identify the acronym as "IMAP".

- Editorial nit, Abstract and Section 2: s/the RFC 2086/RFC 2086/

- A Table of Contents is needed.  Other formatting errors found using the ID nits tool [1] should also be corrected.

- Section 3, 6th paragraph, 1st sentence: "An implementation MAY tie rights together or may".  Is this second "may" supposed to be in lower case letters?

- Section 3, 7th paragraph: "A client may determine".  Again, is this "may" supposed to be in lower case letters?  I won't call out any more, but let's consider this an open question for any other 2119 keywords that appear in both upper and lower case letters.  Consistency is a good thing.

Section 4, first paragraph: s/that have an identifier/that has an identifier/

Section 8: two minor ABNF errors:

capability  =/ rights-capa
command-auth =/ setacl / deleteacl / getacl / listrights / myrights

should be:

capability  = rights-capa
command-auth = setacl / deleteacl / getacl / listrights / myrights

(change "=/" to "=")