idnits 2.17.1 draft-ietf-jmap-smime-12.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 (6 January 2022) is 839 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 6 January 2022 5 Expires: 10 July 2022 7 S/MIME signature verification extension to JMAP 8 draft-ietf-jmap-smime-12 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 10 July 2022. 32 Copyright Notice 34 Copyright (c) 2022 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 4.3. Interaction with Email/changes . . . . . . . . . . . . . 8 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 57 5.1. JMAP capability registration for "smimeverify" . . . . . 9 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 61 7.2. Informative References . . . . . . . . . . . . . . . . . 10 62 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 65 1. Introduction 67 JMAP for Mail [RFC8621] is a JSON-based application protocol for 68 synchronising email data between a client and a server. 70 This document describes an extension to JMAP for returning S/MIME 71 [RFC8551] signature verification status, without requiring a JMAP 72 client to download the signature body part and all signed body parts 73 (when the multipart/signed media type [RFC1847] is used) or to 74 download and decode CMS (when the application/pkcs7-mime media type 75 (Section 3.2 of [RFC8551]) is used). The use of the extension 76 implies the client trusts the JMAP server's S/MIME signature 77 verification code and configuration. This extension is suitable for 78 cases where reduction in network bandwidth and client-side code 79 complexity outweigh security concerns about trusting the JMAP server 80 to perform S/MIME signature verifications. One possible use case is 81 when the same organization controls both the JMAP server and the JMAP 82 client. 84 2. Conventions Used in This Document 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 88 "OPTIONAL" in this document are to be interpreted as described in BCP 89 14 [RFC2119] [RFC8174] when, and only when, they appear in all 90 capitals, as shown here. 92 Type signatures, examples, and property descriptions in this document 93 follow the conventions established in Section 1.1 of [RFC8620]. Data 94 types defined in the core specification are also used in this 95 document. 97 3. Addition to the capabilities object 99 The capabilities object is returned as part of the standard JMAP 100 Session object; see Section 2 of [RFC8620]. Servers supporting 101 _this_ specification MUST add a property called 102 "urn:ietf:params:jmap:smimeverify" to the capabilities object. 104 The value of this property is an empty object in both the JMAP 105 session _capabilities_ property and an account's 106 _accountCapabilities_ property. 108 4. Extension for S/MIME signature verification 110 4.1. Extension to Email/get 112 [RFC8621] defines the Email/get method for retrieving message 113 specific information. This document defines the following pseudo 114 values in the _properties_ argument: 116 * *smimeStatus*: If "smimeStatus" is included in the list of 117 requested properties, it MUST be interpreted by the server as a 118 request to return the "smimeStatus" response property. 120 * *smimeStatusAtDelivery*: If "smimeStatusAtDelivery" is included in 121 the list of requested properties, it MUST be interpreted by the 122 server as a request to return the "smimeStatusAtDelivery" response 123 property. (It is effectively the same as the "smimeStatus" value 124 calculated at the date/time of delivery, as specified by 125 "receivedAt".) 127 * *smimeErrors*: If "smimeErrors" is included in the list of 128 requested properties, it MUST be interpreted by the server as a 129 request to return the "smimeErrors" response property. 131 * *smimeVerifiedAt*: If "smimeVerifiedAt" is included in the list of 132 requested properties, it MUST be interpreted by the server as a 133 request to return the "smimeVerifiedAt" response property. 135 The "smimeStatus" response property is defined as follows: 137 smimeStatus: "String|null" (server-set). null signifies that the 138 message doesn't contain any signature. Otherwise, this property 139 contains the S/MIME signature and certificate verification status 140 calculated according to [RFC8551] and [RFC8550]. Possible string 141 values of the property are listed below. Servers MAY return other 142 values not defined below, as defined in extensions to this document. 143 Clients MUST treat unrecognized values as "unknown" or "signed/ 144 failed". Note that the value of this property might change over 145 time. 147 unknown: S/MIME message, but it was neither signed nor encrypted. 148 This can also be returned for a multipart/signed message which 149 contains an unrecognized signing protocol (for example OpenPGP). 151 signed: S/MIME signed message, but the signature was not yet 152 verified. Some servers might not attempt to verify a signature 153 until a particular message is requested by the client. (This is a 154 useful optimization for a JMAP server to avoid doing work until 155 exact information is needed. A JMAP client that only needs to 156 display an icon that signifies presence of an S/MIME signature can 157 still use this value.) JMAP servers compliant with this document 158 SHOULD attempt signature verification and return "signed/verified" 159 or "signed/failed" instead of this signature status. 161 signed/verified: S/MIME signed message and the sender's signature 162 was successfully verified according to [RFC8551] and [RFC8550]. 163 Additionally the signer email address extracted from the S/MIME 164 certificate matches the From header field value, and the signer 165 certificate SHOULD be checked for revocation. 167 signed/failed: S/MIME signed message, but the signature failed to 168 verify according to [RFC8551] and [RFC8550]. This might be a 169 policy related decision (e.g. the message signer email address 170 doesn't match the From header field value), message was modified, 171 the signer's certificate has expired or was revoked, etc. 173 encrypted+signed/verified: This value is reserved for future use. 174 It is typically handled in the same way as "signed/verified". 176 encrypted+signed/failed: This value is reserved for future use. It 177 is typically handled in the same way as "signed/failed". 179 The "smimeStatusAtDelivery" response property has the same syntax as 180 "smimeStatus" but is calculated in relationship to the "receivedAt" 181 date/time. Unlike "smimeStatus", the "smimeStatusAtDelivery" 182 response property value doesn't change, unless Trust Anchors are 183 added. (For example, addition of a Trust Anchor can change the value 184 of a message "smimeStatusAtDelivery" property from "signed/failed" to 185 "signed/verified". Note that Trust Anchor removal doesn't affect 186 this response property.) The "smimeStatusAtDelivery" allows clients 187 to compare the S/MIME signature verification status at delivery with 188 the current status as returned by "smimeStatus", for example to help 189 to answer questions like "was the signature valid at the time of 190 delivery?". 192 Note that the "smimeStatusAtDelivery" response property value doesn't 193 have to be calculated at delivery time. A JMAP server can defer its 194 calculation until it is explicitly requested, but once calculated its 195 value is remembered for later use. 197 The "smimeErrors" response property is defined as follows: 199 smimeErrors: "String[]|null" (server-set). null signifies that the 200 message doesn't contain any signature or that there were no errors 201 when verifying the S/MIME signature. (I.e., this property is non 202 null only when the corresponding "smimeStatus" response property 203 value is "signed/failed" or "encrypted+signed/failed". Note that 204 future extensions to this document can specify other smimeStatus 205 values that can be used with smimeErrors.) Each string in the array 206 is a human readable description (in the language specified in the 207 Content-Language header field, if any) of a problem with the 208 signature, the signing certificate or the signing certificate chain. 209 (See Section 3.8 of [RFC8620] in regards to how this is affected by 210 the language selection.) In one example, the signing certificate 211 might be expired and the message From email address might not 212 correspond to any of the email addresses in the signing certificate. 213 In another example the certificate might be expired and the JMAP 214 server might be unable to retrieve a CRL for the certificate. In 215 both of these cases there would be 2 elements in the array. 217 The "smimeVerifiedAt" response property is defined as follows: 219 smimeVerifiedAt: "UTCDate|null" (server-set). null signifies that the 220 message doesn't contain any S/MIME signature or that there is a 221 signature, but there was no attempt to verify it. (Retrieval of the 222 smimeStatus value can be used to distinguish these 2 cases). In all 223 other cases it is set to the date and time of when the S/MIME 224 signature was most recently verified. Note that a request to fetch 225 "smimeStatus", "smimeStatusAtDelivery" and/or "smimeErrors" would 226 force this response property to be set to a non null value, if an S/ 227 MIME signature exists. 229 "smimeStatus" and "smimeErrors" values are calculated at the time the 230 corresponding JMAP request was processed (but see below about the 231 effect of result caching), not at the time when the message was 232 generated (according to its Date header field value). In all cases 233 "smimeVerifiedAt" is set to the time when "smimeStatus" and 234 "smimeErrors" were last updated. As recalculating these values is 235 expensive for the server, they MAY be cached for up to 24 hours from 236 the moment when they were calculated. 238 Example 1: Retrieval of minimal information about a message, 239 including its From, Subject and Date header fields, as well as S/MIME 240 signature verification status at delivery and date/time when the 241 message was received. 243 ["Email/get", { 244 "ids": [ "fe123u457" ], 245 "properties": [ "mailboxIds", "from", "subject", "date", 246 "smimeStatusAtDelivery", "receivedAt" ] 247 }, "#1"] 249 This might result in the following response: 251 [["Email/get", { 252 "accountId": "abc", 253 "state": "51234123231", 254 "list": [ 255 { 256 "id": "fe123u457", 257 "mailboxIds": { "f123": true }, 258 "from": [{"name": "Joe Bloggs", "email": "joe@bloggs.example.net"}], 259 "subject": "Dinner tonight?", 260 "date": "2020-07-07T14:12:00Z", 261 "smimeStatusAtDelivery": "signed/verified", 262 "receivedAt": "2020-07-07T14:15:18Z" 263 } 264 ] 265 }, "#1"]] 267 Example 2: Retrieval of minimal information about a message, 268 including its From, Subject and Date header fields, as well as the 269 latest S/MIME signature verification status, S/MIME verification 270 errors (if any) and when was the S/MIME signature status last 271 verified. The response contains 2 S/MIME errors related to S/MIME 272 signature verification. 274 ["Email/get", { 275 "ids": [ "ag123u123" ], 276 "properties": [ "mailboxIds", "from", "subject", "date", 277 "smimeStatus", "smimeErrors", "smimeVerifiedAt" ] 278 }, "#1"] 280 This might result in the following response: 282 [["Email/get", { 283 "accountId": "abc", 284 "state": "47234123231", 285 "list": [ 286 { 287 "id": "ag123u123", 288 "mailboxIds": { "f123": true }, 289 "from": [{"name": "Jane Doe", 290 "email": "jdoe@example.com"}], 291 "subject": "Company takeover", 292 "date": "2020-01-31T23:00:00Z", 293 "smimeStatus": "signed/failed", 294 "smimeErrors": [ 295 "From email address doesn't match the certificate", 296 "Can't retrieve CRL from the CRL URL"], 297 "smimeVerifiedAt": "2020-03-01T12:11:19Z" 298 } 299 ] 300 }, "#1"]] 302 4.1.1. "smimeStatus" response property extensibility 304 Future extensions to this document can specify extra allowed values 305 for the smimeStatus response property. All values (defined in this 306 document or in extensions to this document) MUST be in ASCII. (Note 307 that this response property contains tokens, thus it is not subject 308 to Internationalization or Localization). 310 New smimeStatus response property values defined in extensions may 311 affect behaviour of properties such as smimeErrors response property 312 of Email/get (see Section 4.1) or hasVerifiedSmime property of Email/ 313 query (see Section 4.2). In particular the new values can be treated 314 similar to values defined in this document. 316 For example a putative JMAP extension for automatically decrypting S/ 317 MIME messages can specify two additional values, one specifying that 318 a message is both encrypted and signed with a valid S/MIME signature 319 and another one specifying that a message is both encrypted and 320 signed with an invalid S/MIME signature. The former value can be 321 treated as "signed/verified" (and would thus affect hasVerifiedSmime) 322 and the latter can be treated as "signed/failed" (and thus can be 323 used with smimeErrors). 325 4.2. Extension to Email/query 327 [RFC8621] defines the Email/query method for searching for messages 328 with specific properties. This document defines the following 329 properties of the *FilterCondition* object: 331 * *hasSmime*: "Boolean". If "hasSmime" has the value true, only 332 messages with "smimeStatus" other than null match the condition. 333 If "hasSmime" has the value false, only messages with 334 "smimeStatus" equal to null match the condition. 336 * *hasVerifiedSmime*: "Boolean". If "hasVerifiedSmime" has the 337 value true, only messages with "smimeStatus" equal to "signed/ 338 verified" or "encrypted+signed/verified" (*), match the condition. 339 If "hasVerifiedSmime" has the value false, only messages with 340 "smimeStatus" not equal to "signed/verified" and not equal to 341 "encrypted+signed/verified" (*) (including the value null) match 342 the condition. Note that use of this attribute is potentially 343 expensive for a JMAP server, as it forces calculation of 344 smimeStatus property value for each message. However caching of 345 smimeStatus values should ameliorate this cost somewhat. 347 (*) as well as "smimeStatus" values added by future extensions to 348 this document that are explicitly specified as having similar 349 effect to "signed/verified" as far as "hasVerifiedSmime" 350 calculation is concerned. 352 * *hasVerifiedSmimeAtDelivery*: "Boolean". The 353 "hasVerifiedSmimeAtDelivery" property is handled similar to 354 "hasVerifiedSmime" property, but the value of 355 "smimeStatusAtDelivery" is used instead of "smimeStatus" to assess 356 whether a particular message matches the condition. 358 4.3. Interaction with Email/changes 360 Changes to "smimeVerifiedAt" response property value MUST NOT cause 361 the message to be included in the "updated" argument of Email/changes 362 response. However changes to "smimeStatus", "smimeStatusAtDelivery" 363 and/or "smimeErrors" response properties MUST result in message 364 inclusion in the "updated" argument of Email/changes response. 366 5. IANA Considerations 368 5.1. JMAP capability registration for "smimeverify" 370 IANA is requested to register the "smimeverify" JMAP Capability as 371 follows: 373 Capability Name: "urn:ietf:params:jmap:smimeverify" 375 Specification document: this document 377 Intended use: common 379 Change Controller: IETF 381 Security and privacy considerations: this document, Section 6 383 6. Security Considerations 385 Use of the server-side S/MIME signature verification JMAP extension 386 requires the client to trust the server signature verification code, 387 server configuration and its operational practices to perform S/MIME 388 signature verification, as well as to trust that the channel between 389 the client and the server is integrity protected. (For example, if 390 the server is not configured with some Trust Anchors, some messages 391 will have "signed/failed" status instead of "signed/verified".) A 392 malicious or compromised server could return false verification 393 status to a client. A successful verification could be conveyed to a 394 client for a forged or altered message. A properly signed message 395 could be signaled as having a failed signature verification or no 396 signature at all. In the case of the latter attack, no new attack 397 surface is presented with this extension above what malicious or 398 compromised server could already do by stripping or tampering with 399 the S/MIME information in the message. In the case of the former 400 attack, client software capable of performing S/MIME signature 401 verification could detect this attack. Local configuration of the 402 client should determine if this client-side verification should 403 occur. For clients without local verification capabilities, such an 404 attack would be difficult to detect. 406 Integrity protection of the channel between the client and the server 407 is provided by use of TLS, as required by JMAP specification (see 408 Section 8.1 of [RFC8620]). 410 Constant recalculation of S/MIME signature status can result in a 411 Denial-of-Service condition. For that reason, it is RECOMMENDED that 412 servers cache results of signature verification for up to 24 hours. 414 7. References 416 7.1. Normative References 418 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 419 Requirement Levels", BCP 14, RFC 2119, 420 DOI 10.17487/RFC2119, March 1997, 421 . 423 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 424 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 425 May 2017, . 427 [RFC8550] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 428 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 429 Certificate Handling", RFC 8550, DOI 10.17487/RFC8550, 430 April 2019, . 432 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 433 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 434 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 435 April 2019, . 437 [RFC8620] Jenkins, N. and C. Newman, "The JSON Meta Application 438 Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July 439 2019, . 441 [RFC8621] Jenkins, N. and C. Newman, "The JSON Meta Application 442 Protocol (JMAP) for Mail", RFC 8621, DOI 10.17487/RFC8621, 443 August 2019, . 445 7.2. Informative References 447 [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, 448 "Security Multiparts for MIME: Multipart/Signed and 449 Multipart/Encrypted", RFC 1847, DOI 10.17487/RFC1847, 450 October 1995, . 452 Appendix A. Acknowledgements 454 This document is a product of the JMAP Working Group. Special thank 455 you to Bron Gondwana, Neil Jenkins, Murray Kucherawy, Kirsty Paine, 456 Benjamin Kaduk, Roman Danyliw, Peter Yee, Robert Wilton, Erik Kline 457 and Menachem Dodge for suggestions, comments and corrections to this 458 document. 460 Author's Address 461 Alexey Melnikov 462 Isode Ltd 463 14 Castle Mews 464 Hampton 465 TW12 2NP 466 United Kingdom 468 Email: Alexey.Melnikov@isode.com