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

[Alexey Melnikov <[e-mail]>]

Hi Ben,

Thank you for your throught comments.

On 19/10/2021 23:34, Benjamin Kaduk via Datatracker wrote:
> ----------------------------------------------------------------------
> 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?
My implementation actually does automatic decryption as well, so this 
should work for signed and encrypted messages. But you are right that 
the document doesn't make it very clear that this is an extension point.
> 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.
Added, thank you.
>     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.
Good point. I clarified that future extensions can extend this list.

In my implementation I have a separate smimeWarnings, but it is not 
included in this draft.

>     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".
Ok, I've modified id/state in examples.
>     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?
Are you referencing "#1"?
> 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.

I tried to clarify this by adding a section on smimeStatus 
extensibility, plus some text here.

Best Regards,

Alexey