idnits 2.17.1 draft-ietf-jmap-smime-00.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 6 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 8, 2019) is 1751 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-jmap-core' is defined on line 177, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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 8, 2019 5 Expires: January 9, 2020 7 Extensions to JMAP for S/MIME signature verification 8 draft-ietf-jmap-smime-00 10 Abstract 12 This document specifies 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 9, 2020. 32 Copyright Notice 34 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 55 6.1. JMAP capability registration for "smime" . . . . . . . . 4 56 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 57 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 60 1. Introduction 62 [I-D.ietf-jmap-mail] is a JSON based application protocol for 63 synchronising 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 and all signed body parts or to 68 download and decode CMS. 70 2. Conventions Used in This Document 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in [RFC2119]. 76 3. Addition to the capabilities object 78 The capabilities object is returned as part of the standard JMAP 79 Session object; see the JMAP spec. Servers supporting _this_ 80 specification MUST add a property called "urn:ietf:params:jmap:smime" 81 to the capabilities object. 83 The value of this property is an empty object in both the JMAP 84 session _capabilities_ property and an account's 85 _accountCapabilities_ property. 87 4. Extension to Email/get for S/MIME signature verification 89 [I-D.ietf-jmap-mail] defines Email/get method for retrieving message 90 specific information. This document defines the following pseudo 91 values in the _properties_ argument: 92 o *smimeStatus*: If "smimeStatus" is included in the list of 93 requested properties, it MUST be interpreted by the server as a 94 request to return "smimeStatus" property. 96 The "smimeStatus" response property is defined as follows: 98 *smimeStatus*: "String|null". null signifies that the message doesn't 99 contain any signature. Possible string values of the property are 100 listed below. Servers MAY return other values not defined below. 101 Client MUST treat unrecognized values as "unknown": 103 unknown S/MIME message, but it is neither signed, nor encrypted. 104 This can also be returned for a multipart/signed message which 105 contains unrecognized signing protocol (for example OpenPGP). 107 signed S/MIME signed message, but the signature was not yet 108 verified. Some servers might not attempt to verify signature 109 until a particular message is requested by the client. 111 signed/verified S/MIME signed message and the sender's signature was 112 successfully verified, sender matches the From header field and 113 the sender's certificate (and the certificate chain) is trusted 114 for signing. 116 signed/failed S/MIME signed message, but the signature failed to 117 verify. This might be a policy related decision (message signer 118 doesn't match the From header field), message was modified, the 119 signer's certificate has expired or was revoked, etc. 121 ["Email/get", { 122 "ids": [ "f123u987" ], 123 "properties": [ "mailboxIds", "from", "subject", "date", "smimeStatus" ] 124 }, "#1"] 126 This will result in the following response: 128 [["Email/get", { 129 "accountId": "abc", 130 "state": "41234123231", 131 "list": [ 132 { 133 id: "f123u457", 134 mailboxIds: { "f123": true }, 135 from: [{name: "Joe Bloggs", email: "joe@bloggs.com"}], 136 subject: "Dinner on Thursday?", 137 date: "2013-10-13T14:12:00Z", 138 smimeStatus: "signed/verified" 139 } 140 ] 141 }, "#1"]] 143 Example 145 5. Open Issues 147 [[This section should be empty before publication]] 149 6. IANA Considerations 151 6.1. JMAP capability registration for "smime" 153 IANA is requested to register the "smime" JMAP Capability as follows: 155 Capability Name: "urn:ietf:params:jmap:smime" 157 Specification document: this document 159 Intended use: common 161 Change Controller: IETF 163 Security and privacy considerations: this document, Section 7 165 7. Security Considerations 167 Server side S/MIME signature verification requires the client to 168 trust server verification code and configuration to perform S/MIME 169 signature verification. For example, if the server is not configured 170 with some Trust Anchors, some messages will have "signed/failed" 171 status instead of "signed/verified". 173 TBD. 175 8. Normative References 177 [I-D.ietf-jmap-core] 178 Jenkins, N. and C. Newman, "JSON Meta Application 179 Protocol", draft-ietf-jmap-core-17 (work in progress), 180 March 2019. 182 [I-D.ietf-jmap-mail] 183 Jenkins, N. and C. Newman, "JMAP (JSON Meta Application 184 Protocol) for Mail", draft-ietf-jmap-mail-16 (work in 185 progress), March 2019. 187 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 188 Requirement Levels", BCP 14, RFC 2119, 189 DOI 10.17487/RFC2119, March 1997, 190 . 192 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 193 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 194 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 195 April 2019, . 197 Author's Address 199 Alexey Melnikov 200 Isode Ltd 201 14 Castle Mews 202 Hampton, Middlesex TW12 2NP 203 UK 205 EMail: Alexey.Melnikov@isode.com