idnits 2.17.1 draft-ietf-jmap-smime-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (18 November 2021) is 890 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov 3 Internet-Draft Isode Ltd 4 Intended status: Standards Track 18 November 2021 5 Expires: 22 May 2022 7 S/MIME signature verification extension to JMAP 8 draft-ietf-jmap-smime-11 10 Abstract 12 This document specifies an extension to JMAP for Mail (RFC 8621) for 13 returning S/MIME signature verification status. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on 22 May 2022. 32 Copyright Notice 34 Copyright (c) 2021 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 39 license-info) in effect on the date of publication of this document. 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. Code Components 42 extracted from this document must include Revised BSD License text as 43 described in Section 4.e of the Trust Legal Provisions and are 44 provided without warranty as described in the Revised BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Conventions Used in This Document . . . . . . . . . . . . . . 2 50 3. Addition to the capabilities object . . . . . . . . . . . . . 3 51 4. Extension for S/MIME signature verification . . . . . . . . . 3 52 4.1. Extension to Email/get . . . . . . . . . . . . . . . . . 3 53 4.1.1. "smimeStatus" response property extensibility . . . . 7 54 4.2. Extension to Email/query . . . . . . . . . . . . . . . . 8 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 56 5.1. JMAP capability registration for "smimeverify" . . . . . 8 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 58 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 60 7.2. Informative References . . . . . . . . . . . . . . . . . 10 61 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 64 1. Introduction 66 JMAP for Mail [RFC8621] is a JSON-based application protocol for 67 synchronising email data between a client and a server. 69 This document describes an extension to JMAP for returning S/MIME 70 [RFC8551] signature verification status, without requiring a JMAP 71 client to download the signature body part and all signed body parts 72 (when the multipart/signed media type [RFC1847] is used) or to 73 download and decode CMS (when the application/pkcs7-mime media type 74 (Section 3.2 of [RFC8551]) is used). The use of the extension 75 implies the client trusts the JMAP server's S/MIME signature 76 verification code and configuration. This extension is suitable for 77 cases where reduction in network bandwidth and client-side code 78 complexity outweigh security concerns about trusting the JMAP server 79 to perform S/MIME signature verifications. One possible use case is 80 when the same organization controls both the JMAP server and the JMAP 81 client. 83 2. Conventions Used in This Document 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 87 "OPTIONAL" in this document are to be interpreted as described in BCP 88 14 [RFC2119] [RFC8174] when, and only when, they appear in all 89 capitals, as shown here. 91 Type signatures, examples, and property descriptions in this document 92 follow the conventions established in Section 1.1 of [RFC8620]. Data 93 types defined in the core specification are also used in this 94 document. 96 3. Addition to the capabilities object 98 The capabilities object is returned as part of the standard JMAP 99 Session object; see Section 2 of [RFC8620]. Servers supporting 100 _this_ specification MUST add a property called 101 "urn:ietf:params:jmap:smimeverify" to the capabilities object. 103 The value of this property is an empty object in both the JMAP 104 session _capabilities_ property and an account's 105 _accountCapabilities_ property. 107 4. Extension for S/MIME signature verification 109 4.1. Extension to Email/get 111 [RFC8621] defines the Email/get method for retrieving message 112 specific information. This document defines the following pseudo 113 values in the _properties_ argument: 115 * *smimeStatus*: If "smimeStatus" is included in the list of 116 requested properties, it MUST be interpreted by the server as a 117 request to return the "smimeStatus" response property. 119 * *smimeStatusAtDelivery*: If "smimeStatusAtDelivery" is included in 120 the list of requested properties, it MUST be interpreted by the 121 server as a request to return the "smimeStatusAtDelivery" response 122 property. (It is effectively the same as the "smimeStatus" value 123 calculated at the date/time of delivery, as specified by 124 "receivedAt".) 126 * *smimeErrors*: If "smimeErrors" is included in the list of 127 requested properties, it MUST be interpreted by the server as a 128 request to return the "smimeErrors" response property. 130 * *smimeVerifiedAt*: If "smimeVerifiedAt" is included in the list of 131 requested properties, it MUST be interpreted by the server as a 132 request to return the "smimeVerifiedAt" response property. 134 The "smimeStatus" response property is defined as follows: 136 smimeStatus: "String|null". null signifies that the message doesn't 137 contain any signature. Otherwise, this property contains the S/MIME 138 signature and certificate verification status calculated according to 140 [RFC8551] and [RFC8550]. Possible string values of the property are 141 listed below. Servers MAY return other values not defined below, as 142 defined in extensions to this document. Clients MUST treat 143 unrecognized values as "unknown" or "signed/failed". Note that the 144 value of this property might change over time. 146 unknown: S/MIME message, but it was neither signed nor encrypted. 147 This can also be returned for a multipart/signed message which 148 contains an unrecognized signing protocol (for example OpenPGP). 150 signed: S/MIME signed message, but the signature was not yet 151 verified. Some servers might not attempt to verify a signature 152 until a particular message is requested by the client. (This is a 153 useful optimization for a JMAP server to avoid doing work until 154 exact information is needed. A JMAP client that only needs to 155 display an icon that signifies presence of an S/MIME signature can 156 still use this value.) JMAP servers compliant with this document 157 SHOULD attempt signature verification and return "signed/verified" 158 or "signed/failed" instead of this signature status. 160 signed/verified: S/MIME signed message and the sender's signature 161 was successfully verified according to [RFC8551] and [RFC8550]. 162 Additionally the signer email address extracted from the S/MIME 163 certificate matches the From header field value, and the signer 164 certificate SHOULD be checked for revocation. 166 signed/failed: S/MIME signed message, but the signature failed to 167 verify according to [RFC8551] and [RFC8550]. This might be a 168 policy related decision (e.g. the message signer email address 169 doesn't match the From header field value), message was modified, 170 the signer's certificate has expired or was revoked, etc. 172 encrypted+signed/verified: This value is reserved for future use. 173 It is typically handled in the same way as "signed/verified". 175 encrypted+signed/failed: This value is reserved for future use. It 176 is typically handled in the same way as "signed/failed". 178 The "smimeStatusAtDelivery" response property has the same syntax as 179 "smimeStatus" but is calculated in relationship to the "receivedAt" 180 date/time. Unlike "smimeStatus", the "smimeStatusAtDelivery" 181 response property value doesn't change, unless Trust Anchors are 182 added. (For example, addition of a Trust Anchor can change the value 183 of a message "smimeStatusAtDelivery" property from "signed/failed" to 184 "signed/verified".) The "smimeStatusAtDelivery" allows clients to 185 compare the S/MIME signature verification status at delivery with the 186 current status as returned by "smimeStatus", for example to help to 187 answer questions like "was the signature valid at the time of 188 delivery?". 190 Note that the "smimeStatusAtDelivery" response property value doesn't 191 have to be calculated at delivery time. A JMAP server can defer its 192 calculation until it is explicitly requested, but once calculated its 193 value is remembered for later use. 195 The "smimeErrors" response property is defined as follows: 197 smimeErrors: "String[]|null". null signifies that the message doesn't 198 contain any signature or that there were no errors when verifying the 199 S/MIME signature. (I.e., this property is non null only when the 200 corresponding "smimeStatus" response property value is "signed/ 201 failed" or "encrypted+signed/failed". Note that future extensions to 202 this document can specify other smimeStatus values that can be used 203 with smimeErrors.) Each string in the array is a human readable 204 description (in the language specified in the Content-Language header 205 field, if any) of a problem with the signature, the signing 206 certificate or the signing certificate chain. (See Section 3.8 of 207 [RFC8620] in regards to how this is affected by the language 208 selection.) In one example, the signing certificate might be expired 209 and the message From email address might not correspond to any of the 210 email addresses in the signing certificate. In another example the 211 certificate might be expired and the JMAP server might be unable to 212 retrieve a CRL for the certificate. In both of these cases there 213 would be 2 elements in the array. 215 The "smimeVerifiedAt" response property is defined as follows: 217 smimeVerifiedAt: "UTCDate|null" (server-set). null signifies that the 218 message doesn't contain any S/MIME signature or that there is a 219 signature, but there was no attempt to verify it. (Retrieval of the 220 smimeStatus value can be used to distinguish these 2 cases). In all 221 other cases it is set to the date and time of when the S/MIME 222 signature was most recently verified. Note that a request to fetch 223 "smimeStatus", "smimeStatusAtDelivery" and/or "smimeErrors" would 224 force this response property to be set to a non null value, if an S/ 225 MIME signature exists. 227 "smimeStatus" and "smimeErrors" values are calculated at the time the 228 corresponding JMAP request was processed (but see below about the 229 effect of result caching), not at the time when the message was 230 generated (according to its Date header field value). In all cases 231 "smimeVerifiedAt" is set to the time when "smimeStatus" and 232 "smimeErrors" were last updated. As recalculating these values is 233 expensive for the server, they MAY be cached for up to 24 hours from 234 the moment when they were calculated. 236 Example 1: Retrieval of minimal information about a message, 237 including its From, Subject and Date header fields, as well as S/MIME 238 signature verification status at delivery and date/time when the 239 message was received. 241 ["Email/get", { 242 "ids": [ "fe123u457" ], 243 "properties": [ "mailboxIds", "from", "subject", "date", 244 "smimeStatusAtDelivery", "receivedAt" ] 245 }, "#1"] 247 This might result in the following response: 249 [["Email/get", { 250 "accountId": "abc", 251 "state": "51234123231", 252 "list": [ 253 { 254 "id": "fe123u457", 255 "mailboxIds": { "f123": true }, 256 "from": [{"name": "Joe Bloggs", "email": "joe@bloggs.example.net"}], 257 "subject": "Dinner tonight?", 258 "date": "2020-07-07T14:12:00Z", 259 "smimeStatusAtDelivery": "signed/verified", 260 "receivedAt": "2020-07-07T14:15:18Z" 261 } 262 ] 263 }, "#1"]] 265 Example 2: Retrieval of minimal information about a message, 266 including its From, Subject and Date header fields, as well as the 267 latest S/MIME signature verification status, S/MIME verification 268 errors (if any) and when was the S/MIME signature status last 269 verified. The response contains 2 S/MIME errors related to S/MIME 270 signature verification. 272 ["Email/get", { 273 "ids": [ "ag123u123" ], 274 "properties": [ "mailboxIds", "from", "subject", "date", 275 "smimeStatus", "smimeErrors", "smimeVerifiedAt" ] 276 }, "#1"] 278 This might result in the following response: 280 [["Email/get", { 281 "accountId": "abc", 282 "state": "47234123231", 283 "list": [ 284 { 285 "id": "ag123u123", 286 "mailboxIds": { "f123": true }, 287 "from": [{"name": "Jane Doe", 288 "email": "jdoe@example.com"}], 289 "subject": "Company takeover", 290 "date": "2020-01-31T23:00:00Z", 291 "smimeStatus": "signed/failed", 292 "smimeErrors": [ 293 "From email address doesn't match the certificate", 294 "Can't retrieve CRL from the CRL URL"], 295 "smimeVerifiedAt": "2020-03-01T12:11:19Z" 296 } 297 ] 298 }, "#1"]] 300 4.1.1. "smimeStatus" response property extensibility 302 Future extensions to this document can specify extra allowed values 303 for the smimeStatus response property. All values (defined in this 304 document or in extensions to this document) MUST be in ASCII. (Note 305 that this response property contains tokens, thus it is not subject 306 to Internationalization or Localization). 308 New smimeStatus response property values defined in extensions may 309 affect behaviour of properties such as smimeErrors response property 310 of Email/get (see Section 4.1) or hasVerifiedSmime property of Email/ 311 query (see Section 4.2). In particular the new values can be treated 312 similar to values defined in this document. 314 For example a putative JMAP extension for automatically decrypting S/ 315 MIME messages can specify two additional values, one specifying that 316 a message is both encrypted and signed with a valid S/MIME signature 317 and another one specifying that a message is both encrypted and 318 signed with an invalid S/MIME signature. The former value can be 319 treated as "signed/verified" (and would thus affect hasVerifiedSmime) 320 and the latter can be treated as "signed/failed" (and thus can be 321 used with smimeErrors). 323 4.2. Extension to Email/query 325 [RFC8621] defines the Email/query method for searching for messages 326 with specific properties. This document defines the following 327 properties of the *FilterCondition* object: 329 * *hasSmime*: "Boolean". If "hasSmime" has the value true, only 330 messages with "smimeStatus" other than null match the condition. 331 If "hasSmime" has the value false, only messages with 332 "smimeStatus" equal to null match the condition. 334 * *hasVerifiedSmime*: "Boolean". If "hasVerifiedSmime" has the 335 value true, only messages with "smimeStatus" equal to "signed/ 336 verified" or "encrypted+signed/verified" (*), match the condition. 337 If "hasVerifiedSmime" has the value false, only messages with 338 "smimeStatus" not equal to "signed/verified" and not equal to 339 "encrypted+signed/verified" (*) (including the value null) match 340 the condition. Note that use of this attribute is potentially 341 expensive for a JMAP server, as it forces calculation of 342 smimeStatus property value for each message. However caching of 343 smimeStatus values should ameliorate this cost somewhat. 345 (*) as well as "smimeStatus" values added by future extensions to 346 this document that are explicitly specified as having similar 347 effect to "signed/verified" as far as "hasVerifiedSmime" 348 calculation is concerned. 350 * *hasVerifiedSmimeAtDelivery*: "Boolean". The 351 "hasVerifiedSmimeAtDelivery" property is handled similar to 352 "hasVerifiedSmime" property, but the value of 353 "smimeStatusAtDelivery" is used instead of "smimeStatus" to assess 354 whether a particular message matches the condition. 356 5. IANA Considerations 358 5.1. JMAP capability registration for "smimeverify" 360 IANA is requested to register the "smimeverify" JMAP Capability as 361 follows: 363 Capability Name: "urn:ietf:params:jmap:smimeverify" 365 Specification document: this document 366 Intended use: common 368 Change Controller: IETF 370 Security and privacy considerations: this document, Section 6 372 6. Security Considerations 374 Use of the server-side S/MIME signature verification JMAP extension 375 requires the client to trust the server signature verification code, 376 server configuration and its operational practices to perform S/MIME 377 signature verification, as well as to trust that the channel between 378 the client and the server is integrity protected. (For example, if 379 the server is not configured with some Trust Anchors, some messages 380 will have "signed/failed" status instead of "signed/verified".) A 381 malicious or compromised server could return false verification 382 status to a client. A successful verification could be conveyed to a 383 client for a forged or altered message. A properly signed message 384 could be signaled as having a failed signature verification or no 385 signature at all. In the case of the latter attack, no new attack 386 surface is presented with this extension above what malicious or 387 compromised server could already do by stripping or tampering with 388 the S/MIME information in the message. In the case of the former 389 attack, client software capable of performing S/MIME signature 390 verification could detect this attack. Local configuration of the 391 client should determine if this client-side verification should 392 occur. For clients without local verification capabilities, such an 393 attack would be difficult to detect. 395 Integrity protection of the channel between the client and the server 396 is provided by use of TLS, as required by JMAP specification (see 397 Section 8.1 of [RFC8620]). 399 Constant recalculation of S/MIME signature status can result in a 400 Denial-of-Service condition. For that reason, it is RECOMMENDED to 401 cache results of signature verification for up to 24 hours. 403 7. References 405 7.1. Normative References 407 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 408 Requirement Levels", BCP 14, RFC 2119, 409 DOI 10.17487/RFC2119, March 1997, 410 . 412 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 413 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 414 May 2017, . 416 [RFC8550] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 417 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 418 Certificate Handling", RFC 8550, DOI 10.17487/RFC8550, 419 April 2019, . 421 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 422 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 423 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 424 April 2019, . 426 [RFC8620] Jenkins, N. and C. Newman, "The JSON Meta Application 427 Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July 428 2019, . 430 [RFC8621] Jenkins, N. and C. Newman, "The JSON Meta Application 431 Protocol (JMAP) for Mail", RFC 8621, DOI 10.17487/RFC8621, 432 August 2019, . 434 7.2. Informative References 436 [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, 437 "Security Multiparts for MIME: Multipart/Signed and 438 Multipart/Encrypted", RFC 1847, DOI 10.17487/RFC1847, 439 October 1995, . 441 Appendix A. Acknowledgements 443 This document is a product of JMAP Working Group. Special thank you 444 to Bron Gondwana, Neil Jenkins, Murray Kucherawy, Kirsty Paine, 445 Benjamin Kaduk, Roman Danyliw, Peter Yee, Robert Wilton and Erik 446 Kline for suggestions, comments and corrections to this document. 448 Author's Address 450 Alexey Melnikov 451 Isode Ltd 452 14 Castle Mews 453 Hampton 454 TW12 2NP 455 United Kingdom 457 Email: Alexey.Melnikov@isode.com