S/MIME Signature Verification Extension to the JSON Meta Application Protocol (JMAP)
Extracted elements (22)
The "signed" status value (unverified signature) is retained as a useful optimization: a JMAP server can avoid expensive verification until a client explicitly needs the result, and clients that only need to display a signature-presence icon can use this value.
The "smimeStatusAtDelivery" property is not required to be calculated at delivery time; a JMAP server can defer calculation until explicitly requested, but once calculated the value is remembered. This balances accuracy of historical status with server resource cost.
This extension avoids requiring the JMAP client to download signature body parts or decode CMS, reducing network bandwidth and client-side code complexity. It is suitable when these benefits outweigh security concerns about trusting the JMAP server, such as when the same organization controls both client and server.
The extension is designed so new "smimeStatus" values added by future extensions can be treated similarly to existing values (e.g., a new "encrypted+signed/verified" value can be treated as "signed/verified" for the purposes of "hasVerifiedSmime"), preserving backward compatibility.
All "smimeStatus" response property values (defined in this document or extensions) MUST be in ASCII.
Changes to the "smimeStatus", "smimeStatusAtDelivery", and/or "smimeErrors" response properties MUST result in message inclusion in the "updated" argument of the Email/changes response.
Changes to the "smimeVerifiedAt" response property value MUST NOT cause the message to be included in the "updated" argument of the Email/changes response.
Clients MUST treat unrecognized "smimeStatus" values as "unknown" or "signed/failed".
For the "signed/verified" status, the signer certificate SHOULD be checked for revocation.
If "smimeStatus" is included in the list of requested properties, it MUST be interpreted by the server as a request to return the "smimeStatus" response property.
JMAP servers compliant with this document SHOULD attempt signature verification and return "signed/verified" or "signed/failed" instead of the "signed" status value.
Servers supporting this specification MUST add a property called "urn:ietf:params:jmap:smimeverify" to the capabilities object.
The "smimeStatus" and "smimeErrors" values MAY be cached for up to 24 hours from the moment when they were calculated, as recalculating these values is expensive for the server.
The Email/query FilterCondition is extended with "hasSmime" (Boolean) matching messages where "smimeStatus" is non-null (true) or null (false), "hasVerifiedSmime" (Boolean) matching messages with "smimeStatus" equal to "signed/verified" or "encrypted+signed/verified", and "hasVerifiedSmimeAtDelivery" (Boolean) using "smimeStatusAtDelivery" instead.
The "smimeErrors" response property is a String[]|null (server-set) containing human-readable descriptions of signature verification problems. It is non-null only when "smimeStatus" is "signed/failed" or "encrypted+signed/failed".
The "smimeStatus" response property returns a String|null value representing the S/MIME signature and certificate verification status. Null signifies no signature; possible string values include "unknown", "signed", "signed/verified", "signed/failed", "encrypted+signed/verified", and "encrypted+signed/failed".
The "smimeStatusAtDelivery" response property has the same syntax as "smimeStatus" but is calculated relative to the "receivedAt" date/time. Unlike "smimeStatus", its value does not change unless trust anchors are added (removal of trust anchors does not affect it).
The "smimeVerifiedAt" response property is a UTCDate|null (server-set) indicating when the S/MIME signature was most recently verified. Null means no signature exists or no verification attempt was made.
IANA has registered the JMAP capability "urn:ietf:params:jmap:smimeverify" with intended use "common" and change controller IETF, as specified in RFC 9219.
Constant recalculation of S/MIME signature status can result in a denial-of-service condition. It is RECOMMENDED that servers cache results of signature verification for up to 24 hours.
Integrity protection of the channel between client and server is provided by TLS, as required by the JMAP specification (RFC 8620, Section 8.1).
Using server-side S/MIME verification requires the client to trust the server's verification code, configuration, and operational practices. A malicious or compromised server could return false verification status — conveying successful verification for a forged message or reporting failure for a properly signed one.