[Jmap] Benjamin Kaduk's No Objection on draft-ietf-jmap-smime-09: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-jmap-smime-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-jmap-smime/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Are we asserting that the "smime" prefix for property names (and
"hasSmime", etc.) relates only to S/MIME signing?  How might S/MIME
encryption be handled if support is added in the future?

I see that the opsdir reviewer asked about whether this document should
have an "Updates:" relationship with RFC 8621.  I'm not sure I see a
need for it, myself, but would be interested in hearing the stance of
the authors/WG.

Section 4.1

   signed:  S/MIME signed message, but the signature was not yet
      verified.  Some servers might not attempt to verify a signature
      until a particular message is requested by the client.  JMAP
      servers compliant with this document SHOULD return "signed/
      verified" or "signed/failed" instead of this signature status.

I'd suggest adding something like "SHOULD attempt verification and
return", just to reiterate that servers don't get to arbitrarily claim
verification/failure without doing the verification.

   smimeErrors: "String[]|null". null signifies that the message doesn't
   contain any signature or that there were no errors when verifying the
   S/MIME signature.  (I.e., this property is non null only when the
   corresponding "smimeStatus" response property value is "signed/
   failed".)  [...]

Would some hypothetical future smimeStatus type be compatible with a
non-null smimeErrors?  This phrasing seems to preclude such a
possibility.

   This might result in the following response:

      [["Email/get", {
         "accountId": "abc",
         "state": "41234123231",

I note that this "state" value is used in RFC 8621 when retriving a
similar example message.  As far as I recall this state value represents
only the state of Email objects on the server overall (with some caveat
about visibility to the user), and so it is not inherently inconsistent
to use the same value across examples ... but it might be worth picking
a new value anyway.

The reuse of the message "id" for a message with a different
"receivedAt" date, subject, etc., though, seems less defensible than
reusing "state".

   Example 2: Retrieval of minimal information about a message,
   [...]
         ["Email/get", {
         "ids": [ "af123u123" ],
         "properties": [ "mailboxIds", "from", "subject", "date",
          "smimeStatus", "smimeErrors", "smimeVerifiedAt" ]
         }, "#1"]

Is reusing the method call id allowed?

Section 4.2

   *  *hasVerifiedSmime*: "Boolean".  If "hasVerifiedSmime" has the
      value true, only messages with "smimeStatus" equal to "signed/
      verified" match the condition.  If "hasVerifiedSmime" has the
      value false, only messages with "smimeStatus" not equal to
      "signed/verified" (including the value null) match the condition.

Might some future status value (say, "signed+encrypted/verified") also
need to match as "verified S/MIME"?  This phrasing seems to preclude
such a possibility.

Section 6

The immutability of smimeStatusAtDelivery might have unfortunate
interactions with trust anchor changes (additions, mostly) on the
server, since the state could be locked into invalid even if the current
TA set would have verified it at the time of delivery.

   Use of server-side S/MIME signature verification JMAP extension
   requires the client to trust the server signature verification code
   and configuration to perform S/MIME signature verification.  [...]

I think the client also trusts the channel between client and server, as
well as the server itself.  This is perhaps implicit in trusting the
server, especially when combined with the JMAP requirement for secure
transport, but might still be worth reiterating, as a divergence from
the purely local S/MIME verification mode that is the alternative to
this document's mechanism.

Furthermore, I think it is worth clearly stating that trusting the
server in this way also expands the attack surface -- when this
mechanism is used, the server can be attacked (undetectably by the
client) and return bogus S/MIME verification state, whereas local
verification would have returned correct results.  So the client is not
just trusting the code and configuration of the server, but also its
operational practices.

Roman's text looks like a reasonable way of covering the last two points.

NITS

Section 1

                                         This extension is suitable for
   cases where reduction in network bandwidth and client side code
   complexity outweigh security concerns about trusting JMAP server to
   perform S/MIME signature verifications.  [...]

"the JMAP server".

Section 6

   Use of server-side S/MIME signature verification JMAP extension
   requires the client to trust the server signature verification code
   and configuration to perform S/MIME signature verification.  [...]

"the server-side [...] extension".