S/MIME Signature Verification Extension to the JSON Meta Application Protocol (JMAP)
draft-ietf-jmap-smime-12

Just some random questions that came to mind...

[S4.2, question]

* Is there any benefit to/reason to consider some boolean like
  "hasVerifiedAtDeliverySmime"?

[S5, question]

* In section 4.1, the values of smimeStatus are defined as

   ... Possible string values of the property are
   listed below.  Servers MAY return other values not defined below, as
   defined in extensions to this document.

  If the intention is that documents that update this document are the
  the way to create new possible values, should this imply the establishment
  of a registry of these values?

  But perhaps this level of process is not desired.

Thank you for the work on this document. Many thanks to Kirsty Paine for the ART ART review, and thank you Alexey for addressing Kirsty's comments.

I have one non-DISCUSS question to which I'd really like an answer nonetheless. Given the following text:

   [RFC8551] and [RFC8550].  Possible string values of the property are
   listed below.  Servers MAY return other values not defined below, as
   defined in extensions to this document. 

Would it make sense to define an IANA registry for the allowed values, to guarantee interoperability of implementations?

Francesca

** Section 4.1.   Recommend sticking to verification practices by citation when defining the semantics of “smimeStatus”

OLD
signed/verified:  S/MIME signed message and the sender's signature
      was successfully verified, the sender matches the From header
      field, and the sender's certificate (and the certificate chain) is
      trusted for signing.

   signed/failed:  S/MIME signed message, but the signature failed to
      verify.

NEW
signed/verified:  S/MIME signed message and the sender's signature was successfully verified per the verification process in [RFC8551] and [RFC8550].

signed/failed:  S/MIME signed message, but the signature failed to      verify per the processes in [RFC8551] and [RFC8550].

** Section 6.  Recommend being more explicit with the trust model.

OLD
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.  

NEW
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.  A malicious or compromised server could return false verification status to a client.  A successful verification could be conveyed to a client for a forged or altered message.  A properly signed message could be signaled as having a failed signature verification or no signature at all.  In the case of the latter attack, no new attack surface is presented with this extension above what malicious or compromised server could already do by stripping or tampering with the S/MIME information in the message.  In the case of the former attack, client software capable of performing S/MIME signature verification could detect this attack.  Local configuration of the client should determine if this client-side verification should occur.  For clients without local verification capabilities, such an attack would be difficult to detect.

Thanks to Menachem Dodge for the OpsDir review; I see that the author has incorporated / addressed many of the comments/nits, but I don't think I saw any sort of discussion around the "Please consider whether the document header should indicate "Updates: 8621"." (which Benjamin also referenced). 

It is entirely possible that I completely missed any discussions, but I'd be interested in an answer if possible.

Thank you for the work put into this document. 

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Bron Gondwana for his shepherd's write-up  about the WG consensus.

I hope that this helps to improve the document,

Regards,

-éric


-- Section 4.1 --

I cannot parse the sentence below, probably because of missing quotes or punctuation:
	smimeStatus: "String|null". null signifies that the message doesn't
Suggest to replace with
	smimeStatus: "String|null". A smimeStatus value of "null" signifies that the message doesn't

-- Section 6 --

Just wondering about the cache for 10 minutes only... The amount of information to be stored seems very little so the signature status should be kept until the trust anchors are modified.

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".

Section 6. , paragraph 3, comment:
>    Constant recalculation of S/MIME signature status can result in a
>    Denial-of-Service condition.  For that reason, it is RECOMMENDED to
>    cache results of signature verification for 10 minutes.

Agree with the motivation to cache, but 10 minutes seems pretty arbitrary. Could
a sentence be added giving a bit of context?

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 4.1. , paragraph 13, nit:
> ignature. (I.e., this property is non null only when the corresponding "smime
>                                   ^^^^^^^^
This expression is usually spelled with a hyphen.

Section 4.1. , paragraph 13, nit:
>  Each string in the array is a human readable description (in the language sp
>                                ^^^^^^^^^^^^^^
This word is normally spelled with a hyphen.

Section 4.1. , paragraph 14, nit:
>  (See Section 3.8 of [RFC8620] in regards to how this is affected by the lan
>                                ^^^^^^^^^^^^^
Use "in regard to", "with regard to", or more simply "regarding".

Section 4.1. , paragraph 15, nit:
> s response property to be set to a non null value, if an S/MIME signature exi
>                                    ^^^^^^^^
This expression is usually spelled with a hyphen.

Hi,

I have to confess that I don't know IMAP, and hence my question may have an obvious answer, but it is unclear to me whether a server supporting the smimeverify capability implies that it SHOULD also support checking the S/MIME signature at delivery time?  If this is the case, should this be clarified, perhaps in section 3?

I.e., section 3 states:
   Servers supporting
   _this_ specification MUST add a property called
   "urn:ietf:params:jmap:smimeverify" to the capabilities object.

E.g., section 4.1 states:

   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.

These two statements seem to imply that a server returning the smimeverify capability SHOULD also support checking the S/MIME signature at delivery because they SHOULD either return signed/verified or signed/failed for a request for smimeStatusAtDelivery, which at least implies that they have previously checked the signature when it was delivered.  Is that was is intended?

Thanks,
Rob