idnits 2.17.1 draft-ietf-jmap-smime-02.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 3 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 (July 2, 2020) is 1393 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- 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: Informational July 2, 2020 5 Expires: January 3, 2021 7 S/MIME signature verification extension to JMAP 8 draft-ietf-jmap-smime-02 10 Abstract 12 This document specifies an extension to JMAP for returning S/MIME 13 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 January 3, 2021. 32 Copyright Notice 34 Copyright (c) 2020 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 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Conventions Used in This Document . . . . . . . . . . . . . . 2 51 3. Addition to the capabilities object . . . . . . . . . . . . . 2 52 4. Extension to Email/get for S/MIME signature verification . . 2 53 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 55 6.1. JMAP capability registration for "smime" . . . . . . . . 6 56 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 57 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 60 1. Introduction 62 [RFC8621] is a JSON based application protocol for synchronising 63 email data between a client and a server. 65 This document describes an extension to JMAP for returning S/MIME 66 [RFC8551] signature verification status, without requiring a JMAP 67 client to download the signature body part and all signed body parts 68 (when multipart/signed media type is used) or to download and decode 69 CMS (when application/pkcs7-mime media type is used). 71 2. Conventions Used in This Document 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC2119]. 77 3. Addition to the capabilities object 79 The capabilities object is returned as part of the standard JMAP 80 Session object; see the JMAP spec. Servers supporting _this_ 81 specification MUST add a property called "urn:ietf:params:jmap:smime" 82 to the capabilities object. 84 The value of this property is an empty object in both the JMAP 85 session _capabilities_ property and an account's 86 _accountCapabilities_ property. 88 4. Extension to Email/get for S/MIME signature verification 90 [RFC8621] defines Email/get method for retrieving message specific 91 information. This document defines the following pseudo values in 92 the _properties_ argument: 94 o *smimeStatus*: If "smimeStatus" is included in the list of 95 requested properties, it MUST be interpreted by the server as a 96 request to return "smimeStatus" response property. 97 o *smimeErrors*: If "smimeErrors" is included in the list of 98 requested properties, it MUST be interpreted by the server as a 99 request to return "smimeErrors" response property. 100 o *smimeVerifiedAt*: If "smimeVerifiedAt" is included in the list of 101 requested properties, it MUST be interpreted by the server as a 102 request to return "smimeVerifiedAt" response property. 104 The "smimeStatus" response property is defined as follows: 106 smimeStatus: "String|null". null signifies that the message doesn't 107 contain any signature. This property contains the S/MIME signature 108 and certificate verification status calculated according to [RFC8551] 109 and [RFC8550]. Possible string values of the property are listed 110 below. Servers MAY return other values not defined below. Client 111 MUST treat unrecognized values as "unknown" or "signed/failed". Note 112 that the value of this property might change over time. 114 unknown S/MIME message, but it is neither signed, nor encrypted. 115 This can also be returned for a multipart/signed message which 116 contains unrecognized signing protocol (for example OpenPGP). 118 signed S/MIME signed message, but the signature was not yet 119 verified. Some servers might not attempt to verify signature 120 until a particular message is requested by the client. JMAP 121 servers compliant with this document SHOULD return "signed/ 122 verified" or "signed/failed" instead of this signature status. 124 signed/verified S/MIME signed message and the sender's signature was 125 successfully verified, sender matches the From header field and 126 the sender's certificate (and the certificate chain) is trusted 127 for signing. 129 signed/failed S/MIME signed message, but the signature failed to 130 verify. This might be a policy related decision (message signer 131 doesn't match the From header field), message was modified, the 132 signer's certificate has expired or was revoked, etc. 134 The "smimeErrors" response property is defined as follows: 136 smimeErrors: "String[]|null". null signifies that the message doesn't 137 contain any signature or that there were no errors when verifying 138 S/MIME signature. (I.e. this property is non null only when the 139 corresponding "smimeStatus" response property value is "signed/ 140 failed".) Each string in the array is a human readable description 141 (in the language specified in Content-Language header field, if any) 142 of a problem with the signature or the signing certificate. (See 143 Section 3.8 of [RFC8620] in regards to how this is affected by the 144 language selection.) For example, the signing certificate might be 145 expired and the message From email address might not correspond to 146 any of the email addresses in the signing certificate. Or the 147 certificate might be expired and the JMAP server might be unable to 148 retrieve CRL for the certificate. In both of these cases there would 149 be 2 elements in the array. 151 The "smimeVerifiedAt" response property is defined as follows: 153 smimeVerifiedAt: "UTCDate|null" (server-set). null signifies that the 154 message doesn't contain any S/MIME signature or that there is a 155 signature, but there was no attempt to verify it. In all other cases 156 it is set to the date and time of when S/MIME signature was verified 157 the last time. 159 "smimeStatus" and "smimeErrors" values are calculated at the time the 160 corresponding JMAP request was processed, not at the time when the 161 message was generated (according to it's Date header field value). 162 It MAY be calculated at the time the message was delivered to the 163 mailbox. In all cases "smimeVerifiedAt" is set to time when 164 "smimeStatus" and "smimeErrors" were last updated. As recalculating 165 these values is expensive for the server they MAY be cached for up to 166 10 minutes from the moment when they were calculated. 168 ["Email/get", { 169 "ids": [ "f123u987" ], 170 "properties": [ "mailboxIds", "from", "subject", "date", 171 "smimeStatus" ] 172 }, "#1"] 174 This will result in the following response: 176 [["Email/get", { 177 "accountId": "abc", 178 "state": "41234123231", 179 "list": [ 180 { 181 id: "f123u457", 182 mailboxIds: { "f123": true }, 183 from: [{name: "Joe Bloggs", email: "joe@bloggs.example.net"}], 184 subject: "Dinner tonight?", 185 date: "2020-07-07T14:12:00Z", 186 smimeStatus: "signed/verified" 187 } 188 ] 189 }, "#1"]] 191 Example 1: 193 ["Email/get", { 194 "ids": [ "af123u123" ], 195 "properties": [ "mailboxIds", "from", "subject", "date", 196 "smimeStatus", "smimeErrors", "smimeVerifiedAt" ] 197 }, "#1"] 199 This will result in the following response: 201 [["Email/get", { 202 "accountId": "abc", 203 "state": "41234123231", 204 "list": [ 205 { 206 id: "af123u123", 207 mailboxIds: { "f123": true }, 208 from: [{name: "Jane Doe", 209 email: "jdoe@example.com"}], 210 subject: "Company takeover", 211 date: "2020-01-31T23:00:00Z", 212 smimeStatus: "signed/failed", 213 smimeErrors: [ 214 "From email address doesn't match the certificate", 215 "Can't retrieve CRL from the CRL URL"], 216 "smimeVerifiedAt": "2020-03-01T12:11:19Z" 217 } 218 ] 219 }, "#1"]] 221 Example 2: 223 5. Open Issues 225 [[This section should be empty before publication]] 227 1. Should a new property be added on requests to allow signature 228 verification "at specified time"? 230 6. IANA Considerations 232 6.1. JMAP capability registration for "smime" 234 IANA is requested to register the "smime" JMAP Capability as follows: 236 Capability Name: "urn:ietf:params:jmap:smime" 238 Specification document: this document 240 Intended use: common 241 Change Controller: IETF 243 Security and privacy considerations: this document, Section 7 245 7. Security Considerations 247 Server side S/MIME signature verification requires the client to 248 trust server verification code and configuration to perform S/MIME 249 signature verification. For example, if the server is not configured 250 with some Trust Anchors, some messages will have "signed/failed" 251 status instead of "signed/verified". 253 Constant recalculation of S/MIME signature status can result in 254 Denial-of-Service condition. For that reason it is RECOMMENDED to 255 cache results of signature verification for 10 minutes. 257 8. Normative References 259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 260 Requirement Levels", BCP 14, RFC 2119, 261 DOI 10.17487/RFC2119, March 1997, 262 . 264 [RFC8550] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 265 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 266 Certificate Handling", RFC 8550, DOI 10.17487/RFC8550, 267 April 2019, . 269 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 270 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 271 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 272 April 2019, . 274 [RFC8620] Jenkins, N. and C. Newman, "The JSON Meta Application 275 Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July 276 2019, . 278 [RFC8621] Jenkins, N. and C. Newman, "The JSON Meta Application 279 Protocol (JMAP) for Mail", RFC 8621, DOI 10.17487/RFC8621, 280 August 2019, . 282 Author's Address 283 Alexey Melnikov 284 Isode Ltd 285 14 Castle Mews 286 Hampton, Middlesex TW12 2NP 287 UK 289 EMail: Alexey.Melnikov@isode.com