Subject: [Jmap] Roman Danyliw's No Objection on draft-ietf-jmap-smime-09: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Mon, 18 Oct 2021 17:09:03 -0700

Roman Danyliw 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:
----------------------------------------------------------------------

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

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 21 Oct 2021 15:16:49 +0100

Hi Roman,

[RFC8551] and [RFC8550] are already listed earlier on when smimeStatus 
is described in more general terms, so implementing your suggestion 
becomes less urgent. Let me think a bit more about the best way of 
updating the draft to reflect this comment.
> attack would be difficult to detect.

Sounds good to me. Added to my copy of -10.

Thank you,

Alexey