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

[Alexey Melnikov <[e-mail]>]

Hi Roman,

On 19/10/2021 01:09, Roman Danyliw via Datatracker wrote:
> ----------------------------------------------------------------------
> 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].
[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.
> ** 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.

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

Thank you,

Alexey