5Internet Engineering Task Force (IETF) A. Melnikov
6Request for Comments: 9219 Isode Ltd
7Category: Standards Track April 2022
11 S/MIME Signature Verification Extension to the JSON Meta Application
16 This document specifies an extension to "The JSON Meta Application
17 Protocol (JMAP) for Mail" (RFC 8621) for returning the S/MIME
18 signature verification status.
22 This is an Internet Standards Track document.
24 This document is a product of the Internet Engineering Task Force
25 (IETF). It represents the consensus of the IETF community. It has
26 received public review and has been approved for publication by the
27 Internet Engineering Steering Group (IESG). Further information on
28 Internet Standards is available in Section 2 of RFC 7841.
30 Information about the current status of this document, any errata,
31 and how to provide feedback on it may be obtained at
32 https://www.rfc-editor.org/info/rfc9219.
36 Copyright (c) 2022 IETF Trust and the persons identified as the
37 document authors. All rights reserved.
39 This document is subject to BCP 78 and the IETF Trust's Legal
40 Provisions Relating to IETF Documents
41 (https://trustee.ietf.org/license-info) in effect on the date of
42 publication of this document. Please review these documents
43 carefully, as they describe your rights and restrictions with respect
44 to this document. Code Components extracted from this document must
45 include Revised BSD License text as described in Section 4.e of the
46 Trust Legal Provisions and are provided without warranty as described
47 in the Revised BSD License.
52 2. Conventions Used in This Document
53 3. Addition to the Capabilities Object
54 4. Extension for S/MIME Signature Verification
55 4.1. Extension to Email/get
56 4.1.1. "smimeStatus" Response Property Extensibility
57 4.2. Extension to Email/query
58 4.3. Interaction with Email/changes
59 5. IANA Considerations
60 5.1. JMAP Capability Registration for "smimeverify"
61 6. Security Considerations
63 7.1. Normative References
64 7.2. Informative References
70 JMAP for Mail [RFC8621] is a JSON-based application protocol for
71 synchronizing email data between a client and a server.
73 This document describes an extension to JMAP for returning the S/MIME
74 signature verification status [RFC8551], without requiring a JMAP
75 client to download the signature body part and all signed body parts
76 (when the multipart/signed media type [RFC1847] is used) or to
77 download and decode the Cryptographic Message Syntax (CMS) (when the
78 application/pkcs7-mime media type (Section 3.2 of [RFC8551]) is
79 used). The use of the extension implies the client trusts the JMAP
80 server's S/MIME signature verification code and configuration. This
81 extension is suitable for cases where reduction in network bandwidth
82 and client-side code complexity outweigh security concerns about
83 trusting the JMAP server to perform S/MIME signature verifications.
84 One possible use case is when the same organization controls both the
85 JMAP server and the JMAP client.
872. Conventions Used in This Document
89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
91 "OPTIONAL" in this document are to be interpreted as described in BCP
92 14 [RFC2119] [RFC8174] when, and only when, they appear in all
93 capitals, as shown here.
95 Type signatures, examples, and property descriptions in this document
96 follow the conventions established in Section 1.1 of [RFC8620]. Data
97 types defined in the core specification are also used in this
1003. Addition to the Capabilities Object
102 The *capabilities* object is returned as part of the standard JMAP
103 Session object; see Section 2 of [RFC8620]. Servers supporting this
104 specification MUST add a property called
105 "urn:ietf:params:jmap:smimeverify" to the capabilities object.
107 The value of this property is an empty object in both the JMAP
108 Session _capabilities_ property and an account's
109 _accountCapabilities_ property.
1114. Extension for S/MIME Signature Verification
1134.1. Extension to Email/get
115 [RFC8621] defines the Email/get method for retrieving message-
116 specific information. This document defines the following pseudo
117 values in the _properties_ argument:
120 If "smimeStatus" is included in the list of requested properties,
121 it MUST be interpreted by the server as a request to return the
122 "smimeStatus" response property.
124 *smimeStatusAtDelivery*:
125 If "smimeStatusAtDelivery" is included in the list of requested
126 properties, it MUST be interpreted by the server as a request to
127 return the "smimeStatusAtDelivery" response property. (It is
128 effectively the same as the "smimeStatus" value calculated at the
129 date/time of delivery, as specified by "receivedAt".)
132 If "smimeErrors" is included in the list of requested properties,
133 it MUST be interpreted by the server as a request to return the
134 "smimeErrors" response property.
137 If "smimeVerifiedAt" is included in the list of requested
138 properties, it MUST be interpreted by the server as a request to
139 return the "smimeVerifiedAt" response property.
141 The "smimeStatus" response property is defined as follows:
144 "String|null" (server-set). null signifies that the message
145 doesn't contain any signature. Otherwise, this property contains
146 the S/MIME signature and certificate verification status
147 calculated according to [RFC8551], [RFC8550], and [RFC5280].
148 Possible string values of the property are listed below. Servers
149 MAY return other values not defined below, as defined in
150 extensions to this document. Clients MUST treat unrecognized
151 values as "unknown" or "signed/failed". Note that the value of
152 this property might change over time.
155 An S/MIME message, but it was neither signed nor encrypted.
156 This can also be returned for a multipart/signed message that
157 contains an unrecognized signing protocol (for example,
161 An S/MIME signed message, but the signature was not yet
162 verified. Some servers might not attempt to verify a signature
163 until a particular message is requested by the client. (This
164 is a useful optimization for a JMAP server to avoid doing work
165 until exact information is needed. A JMAP client that only
166 needs to display an icon that signifies presence of an S/MIME
167 signature can still use this value.) JMAP servers compliant
168 with this document SHOULD attempt signature verification and
169 return "signed/verified" or "signed/failed" instead of this
173 An S/MIME signed message, and the sender's signature was
174 successfully verified according to [RFC8551] and [RFC8550].
175 Additionally, the signer email address extracted from the S/
176 MIME certificate matches the From header field value, and the
177 signer certificate SHOULD be checked for revocation.
180 S/MIME signed message, but the signature failed to verify
181 according to [RFC8551] and [RFC8550]. This might be because of
182 a policy-related decision (e.g., the message signer email
183 address doesn't match the From header field value), the message
184 was modified, the signer's certificate has expired or was
187 encrypted+signed/verified:
188 This value is reserved for future use. It is typically handled
189 in the same way as "signed/verified".
191 encrypted+signed/failed:
192 This value is reserved for future use. It is typically handled
193 in the same way as "signed/failed".
195 The "smimeStatusAtDelivery" response property has the same syntax as
196 "smimeStatus" but is calculated in relationship to the "receivedAt"
197 date/time. Unlike "smimeStatus", the "smimeStatusAtDelivery"
198 response property value doesn't change unless trust anchors are
199 added. (For example, addition of a trust anchor can change the value
200 of a message "smimeStatusAtDelivery" property from "signed/failed" to
201 "signed/verified". Note that trust anchor removal doesn't affect
202 this response property.) The "smimeStatusAtDelivery" response
203 property value allows clients to compare the S/MIME signature
204 verification status at delivery with the current status as returned
205 by "smimeStatus", for example, to help to answer questions like "was
206 the signature valid at the time of delivery?".
208 Note that the "smimeStatusAtDelivery" response property value doesn't
209 have to be calculated at delivery time. A JMAP server can defer its
210 calculation until it is explicitly requested; however, once it is
211 calculated, its value is remembered for later use.
213 The "smimeErrors" response property is defined as follows:
216 "String[]|null" (server-set). null signifies that the message
217 doesn't contain any signature or that there were no errors when
218 verifying the S/MIME signature. (That is, this property is non-
219 null only when the corresponding "smimeStatus" response property
220 value is "signed/failed" or "encrypted+signed/failed". Note that
221 future extensions to this document can specify other "smimeStatus"
222 values that can be used with "smimeErrors".) Each string in the
223 array is a human-readable description (in the language specified
224 in the Content-Language header field, if any) of a problem with
225 the signature, the signing certificate, or the signing certificate
226 chain. (See Section 3.8 of [RFC8620] in regards to how this is
227 affected by the language selection.) In one example, the signing
228 certificate might be expired and the message From email address
229 might not correspond to any of the email addresses in the signing
230 certificate. In another example, the certificate might be expired
231 and the JMAP server might be unable to retrieve a Certificate
232 Revocation List (CRL) for the certificate. In both of these
233 cases, there would be 2 elements in the array.
235 The "smimeVerifiedAt" response property is defined as follows:
238 "UTCDate|null" (server-set). null signifies that the message
239 doesn't contain any S/MIME signature or that there is a signature,
240 but there was no attempt to verify it. (Retrieval of the
241 "smimeStatus" value can be used to distinguish these 2 cases). In
242 all other cases, it is set to the date and time of when the S/MIME
243 signature was most recently verified. Note that a request to
244 fetch "smimeStatus", "smimeStatusAtDelivery", and/or "smimeErrors"
245 would force this response property to be set to a non-null value
246 if an S/MIME signature exists.
248 The "smimeStatus" and "smimeErrors" values are calculated at the time
249 the corresponding JMAP request is processed (but see below about the
250 effect of result caching), not at the time when the message is
251 generated (according to its Date header field value). In all cases,
252 "smimeVerifiedAt" is set to the time when "smimeStatus" and
253 "smimeErrors" were last updated. As recalculating these values is
254 expensive for the server, they MAY be cached for up to 24 hours from
255 the moment when they were calculated.
257 Example 1: Retrieval of minimal information about a message,
258 including its From, Subject, and Date header fields, as well as the
259 S/MIME signature verification status at delivery and date/time when
260 the message was received.
263 "ids": [ "fe123u457" ],
264 "properties": [ "mailboxIds", "from", "subject", "date",
265 "smimeStatusAtDelivery", "receivedAt" ]
268 This might result in the following response:
272 "state": "51234123231",
276 "mailboxIds": { "f123": true },
277 "from": [{"name": "Joe Bloggs",
278 "email": "joe@bloggs.example.net"}],
279 "subject": "Dinner tonight?",
280 "date": "2020-07-07T14:12:00Z",
281 "smimeStatusAtDelivery": "signed/verified",
282 "receivedAt": "2020-07-07T14:15:18Z"
287 Example 2: Retrieval of minimal information about a message,
288 including its From, Subject, and Date header fields, as well as the
289 latest S/MIME signature verification status, S/MIME verification
290 errors (if any), and when the S/MIME signature status was last
291 verified. The response contains 2 S/MIME errors related to S/MIME
292 signature verification.
295 "ids": [ "ag123u123" ],
296 "properties": [ "mailboxIds", "from", "subject", "date",
297 "smimeStatus", "smimeErrors", "smimeVerifiedAt" ]
300 This might result in the following response:
304 "state": "47234123231",
308 "mailboxIds": { "f123": true },
309 "from": [{"name": "Jane Doe",
310 "email": "jdoe@example.com"}],
311 "subject": "Company takeover",
312 "date": "2020-01-31T23:00:00Z",
313 "smimeStatus": "signed/failed",
315 "From email address doesn't match the certificate",
316 "Can't retrieve CRL from the CRL URL"],
317 "smimeVerifiedAt": "2020-03-01T12:11:19Z"
3224.1.1. "smimeStatus" Response Property Extensibility
324 Future extensions to this document can specify extra allowed values
325 for the "smimeStatus" response property. All values (defined in this
326 document or in extensions to this document) MUST be in ASCII. (Note
327 that this response property contains tokens; thus, it is not subject
328 to internationalization or localization).
330 New "smimeStatus" response property values defined in extensions may
331 affect the behavior of properties, such as the "smimeErrors" response
332 property of Email/get (see Section 4.1) or the "hasVerifiedSmime"
333 property of Email/query (see Section 4.2). In particular, the new
334 values can be treated similarly to values defined in this document.
336 For example, a putative JMAP extension for automatically decrypting
337 S/MIME messages can specify two additional values, one specifying
338 that a message is both encrypted and signed with a valid S/MIME
339 signature (e.g. "encrypted+signed/verified") and another one
340 specifying that a message is both encrypted and signed with an
341 invalid S/MIME signature (e.g. "encrypted+signed/failed"). The
342 former value can be treated as "signed/verified" (and would thus
343 affect "hasVerifiedSmime") and the latter can be treated as "signed/
344 failed" (and thus can be used with "smimeErrors").
3464.2. Extension to Email/query
348 [RFC8621] defines the Email/query method for searching for messages
349 with specific properties. This document defines the following
350 properties of the *FilterCondition* object:
353 "Boolean". If "hasSmime" has the value true, only messages with
354 "smimeStatus" other than null match the condition. If "hasSmime"
355 has the value false, only messages with "smimeStatus" equal to
356 null match the condition.
359 "Boolean". If "hasVerifiedSmime" has the value true, only
360 messages with "smimeStatus" equal to "signed/verified" or
361 "encrypted+signed/verified" (*) match the condition. If
362 "hasVerifiedSmime" has the value false, only messages with
363 "smimeStatus" not equal to "signed/verified" and not equal to
364 "encrypted+signed/verified" (*) (including the value null) match
365 the condition. Note that use of this attribute is potentially
366 expensive for a JMAP server, as it forces calculation of the
367 "smimeStatus" property value for each message. However, caching
368 of the "smimeStatus" values should ameliorate this cost somewhat.
370 (*) as well as the "smimeStatus" values added by future extensions
371 to this document that are explicitly specified as having similar
372 effect to "signed/verified" as far as "hasVerifiedSmime"
373 calculation is concerned.
375 *hasVerifiedSmimeAtDelivery*:
376 "Boolean". The "hasVerifiedSmimeAtDelivery" property is handled
377 similarly to the "hasVerifiedSmime" property, but the value of
378 "smimeStatusAtDelivery" is used instead of "smimeStatus" to assess
379 whether a particular message matches the condition.
3814.3. Interaction with Email/changes
383 Changes to the "smimeVerifiedAt" response property value MUST NOT
384 cause the message to be included in the "updated" argument of the
385 Email/changes response. However, changes to the "smimeStatus",
386 "smimeStatusAtDelivery", and/or "smimeErrors" response properties
387 MUST result in message inclusion in the "updated" argument of the
388 Email/changes response.
3905. IANA Considerations
3925.1. JMAP Capability Registration for "smimeverify"
394 IANA has registered the "smimeverify" JMAP capability as follows:
396 Capability Name: urn:ietf:params:jmap:smimeverify
397 Specification document: RFC 9219
399 Change Controller: IETF
400 Security and privacy considerations: RFC 9219, Section 6
4026. Security Considerations
404 Use of the server-side S/MIME signature verification JMAP extension
405 requires the client to trust the server signature verification code,
406 the server configuration, and the server's operational practices to
407 perform S/MIME signature verification, as well as to trust that the
408 channel between the client and the server is integrity protected.
409 (For example, if the server is not configured with some trust
410 anchors, some messages will have the "signed/failed" status instead
411 of "signed/verified".) A malicious or compromised server could
412 return a false verification status to a client. A successful
413 verification could be conveyed to a client for a forged or altered
414 message. A properly signed message could be signaled as having a
415 failed signature verification or no signature at all. In the case of
416 the latter attack, no new attack surface is presented with this
417 extension above what a malicious or compromised server could already
418 do by stripping or tampering with the S/MIME information in the
419 message. In the case of the former attack, client software capable
420 of performing S/MIME signature verification could detect this attack.
421 Local configuration of the client should determine if this client-
422 side verification should occur. For clients without local
423 verification capabilities, such an attack would be difficult to
426 Integrity protection of the channel between the client and the server
427 is provided by use of TLS, as required by the JMAP specification (see
428 Section 8.1 of [RFC8620]).
430 Constant recalculation of the S/MIME signature status can result in a
431 denial-of-service condition. For that reason, it is RECOMMENDED that
432 servers cache results of signature verification for up to 24 hours.
4367.1. Normative References
438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
439 Requirement Levels", BCP 14, RFC 2119,
440 DOI 10.17487/RFC2119, March 1997,
441 <https://www.rfc-editor.org/info/rfc2119>.
443 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
444 Housley, R., and W. Polk, "Internet X.509 Public Key
445 Infrastructure Certificate and Certificate Revocation List
446 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
447 <https://www.rfc-editor.org/info/rfc5280>.
449 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
450 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
451 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
453 [RFC8550] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
454 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
455 Certificate Handling", RFC 8550, DOI 10.17487/RFC8550,
456 April 2019, <https://www.rfc-editor.org/info/rfc8550>.
458 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
459 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
460 Message Specification", RFC 8551, DOI 10.17487/RFC8551,
461 April 2019, <https://www.rfc-editor.org/info/rfc8551>.
463 [RFC8620] Jenkins, N. and C. Newman, "The JSON Meta Application
464 Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July
465 2019, <https://www.rfc-editor.org/info/rfc8620>.
467 [RFC8621] Jenkins, N. and C. Newman, "The JSON Meta Application
468 Protocol (JMAP) for Mail", RFC 8621, DOI 10.17487/RFC8621,
469 August 2019, <https://www.rfc-editor.org/info/rfc8621>.
4717.2. Informative References
473 [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
474 "Security Multiparts for MIME: Multipart/Signed and
475 Multipart/Encrypted", RFC 1847, DOI 10.17487/RFC1847,
476 October 1995, <https://www.rfc-editor.org/info/rfc1847>.
480 This document is a product of the JMAP Working Group. Special thank
481 you to Bron Gondwana, Neil Jenkins, Murray Kucherawy, Kirsty Paine,
482 Benjamin Kaduk, Roman Danyliw, Peter Yee, Robert Wilton, Erik Kline,
483 and Menachem Dodge for suggestions, comments, and corrections to this
494 Email: Alexey.Melnikov@isode.com