<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-jmap-smime-12" indexInclude="true" ipr="trust200902" number="9219" prepTime="2022-04-05T11:54:35" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-jmap-smime-12" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9219" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="JMAP Extension for S/MIME">S/MIME Signature Verification Extension to the JSON Meta Application Protocol (JMAP)</title>
    <seriesInfo name="RFC" value="9219" stream="IETF"/>
    <author initials="A." surname="Melnikov" fullname="Alexey Melnikov">
      <organization showOnFrontPage="true">Isode Ltd</organization>
      <address>
        <postal>
          <street>14 Castle Mews</street>
          <city>Hampton, Middlesex</city>
          <code>TW12 2NP</code>
          <country>United Kingdom</country>
        </postal>
        <email>Alexey.Melnikov@isode.com</email>
      </address>
    </author>
    <date month="04" year="2022"/>
    <keyword>JMAP</keyword>
    <keyword>S/MIME</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">
	This document specifies an extension to "The JSON Meta Application Protocol
	(JMAP) for Mail" (RFC 8621) for returning the S/MIME signature verification status.
      </t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9219" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2022 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conventions-used-in-this-do">Conventions Used in This Document</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-addition-to-the-capabilitie">Addition to the Capabilities Object</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-extension-for-s-mime-signat">Extension for S/MIME Signature Verification</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-extension-to-email-get">Extension to Email/get</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.1.2">
                  <li pn="section-toc.1-1.4.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.1.1"><xref derivedContent="4.1.1" format="counter" sectionFormat="of" target="section-4.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-smimestatus-response-proper">"smimeStatus" Response Property Extensibility</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-extension-to-email-query">Extension to Email/query</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interaction-with-email-chan">Interaction with Email/changes</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-jmap-capability-registratio">JMAP Capability Registration for "smimeverify"</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">
        <xref target="RFC8621" format="default" sectionFormat="of" derivedContent="RFC8621">JMAP for Mail</xref> is a JSON-based application protocol for synchronizing email data
        between a client and a server.
      </t>
      <t indent="0" pn="section-1-2">
        This document describes an extension to JMAP for returning the S/MIME
        signature verification status <xref target="RFC8551" format="default" sectionFormat="of" derivedContent="RFC8551"/>, without requiring a JMAP client to download the
        signature body part and all signed body parts (when the
        multipart/signed media type <xref target="RFC1847" format="default" sectionFormat="of" derivedContent="RFC1847"/>
        is used) or to download and decode the Cryptographic Message Syntax (CMS)
        (when the application/pkcs7-mime media type (<xref target="RFC8551" section="3.2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8551#section-3.2" derivedContent="RFC8551"/>) is used).  The
        use of the extension implies the client trusts the JMAP server's
        S/MIME signature verification code and configuration.  This extension
        is suitable for cases where reduction in network bandwidth and
        client-side code complexity outweigh security concerns about trusting
        the JMAP server to perform S/MIME signature verifications. One
        possible use case is when the same organization controls both the JMAP
        server and the JMAP client.
      </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-conventions-used-in-this-do">Conventions Used in This Document</name>
      <t indent="0" pn="section-2-1">The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
         "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>",
         and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in
         BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they
         appear in all capitals, as shown here.
      </t>
      <t indent="0" pn="section-2-2">
      Type signatures, examples, and property descriptions in this document
      follow the conventions established in <xref target="RFC8620" section="1.1" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8620#section-1.1" derivedContent="RFC8620"/>.
      Data types defined in the core specification are also used in this document.
      </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-addition-to-the-capabilitie">Addition to the Capabilities Object</name>
      <t indent="0" pn="section-3-1">
        The <strong>capabilities</strong> object is returned as part of the standard JMAP
        Session object; see <xref target="RFC8620" section="2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8620#section-2" derivedContent="RFC8620"/>.
        Servers supporting this
        specification <bcp14>MUST</bcp14> add a property called
        "urn:ietf:params:jmap:smimeverify" to the capabilities object.
      </t>
      <t indent="0" pn="section-3-2">
        The value of this property is an empty object in both the JMAP
        Session <em>capabilities</em> property and an account's
        <em>accountCapabilities</em> property.
      </t>
    </section>
    <section anchor="smime" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-extension-for-s-mime-signat">Extension for S/MIME Signature Verification</name>
      <section anchor="email-get-ext" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-extension-to-email-get">Extension to Email/get</name>
        <t indent="0" pn="section-4.1-1">
      
        <xref target="RFC8621" format="default" sectionFormat="of" derivedContent="RFC8621"/> defines the Email/get method for retrieving message-specific information.
        This document defines the following pseudo values in the <em>properties</em> argument:</t>
        <dl newline="true" spacing="normal" indent="3" pn="section-4.1-2">
          <dt pn="section-4.1-2.1"><strong>smimeStatus</strong>:</dt>
          <dd pn="section-4.1-2.2">If "smimeStatus" is included in the list of requested
          properties, it <bcp14>MUST</bcp14> be interpreted by the server as a request to
          return the "smimeStatus" response property.</dd>
          <dt pn="section-4.1-2.3"><strong>smimeStatusAtDelivery</strong>:</dt>
          <dd pn="section-4.1-2.4">If "smimeStatusAtDelivery" is included in the list of requested
        properties, it <bcp14>MUST</bcp14> be interpreted by the server as a request to
        return the "smimeStatusAtDelivery" response property. (It is effectively the same as
	the "smimeStatus"
        value calculated at the date/time of delivery, as specified by "receivedAt".)</dd>
          <dt pn="section-4.1-2.5"><strong>smimeErrors</strong>:</dt>
          <dd pn="section-4.1-2.6">If "smimeErrors" is included in the list of requested
        properties, it <bcp14>MUST</bcp14> be interpreted by the server as a request to
        return the "smimeErrors" response property.</dd>
          <dt pn="section-4.1-2.7"><strong>smimeVerifiedAt</strong>:</dt>
          <dd pn="section-4.1-2.8">If "smimeVerifiedAt" is included in the list of requested
        properties, it <bcp14>MUST</bcp14> be interpreted by the server as a request to
        return the "smimeVerifiedAt" response property.</dd>
        </dl>
        <t indent="0" pn="section-4.1-3">The "smimeStatus" response property is defined as follows:</t>
        <dl newline="true" spacing="normal" indent="3" pn="section-4.1-4">
          <dt pn="section-4.1-4.1"><strong>smimeStatus</strong>:</dt>
          <dd pn="section-4.1-4.2">
            <t indent="0" pn="section-4.1-4.2.1">"String|null" (server-set). null signifies that the message doesn't
        contain any signature. Otherwise, this property contains the S/MIME signature
        and certificate verification status calculated according to
        <xref target="RFC8551" format="default" sectionFormat="of" derivedContent="RFC8551"/>, <xref target="RFC8550" format="default" sectionFormat="of" derivedContent="RFC8550"/>, and <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/>.
        Possible string values of the property are
        listed below.  Servers <bcp14>MAY</bcp14> return other values not defined below,
        as defined in extensions to this document.
        Clients <bcp14>MUST</bcp14> treat unrecognized values as "unknown" or "signed/failed".
        Note that the value of this property might change over time.</t>
            <dl newline="true" spacing="normal" indent="3" pn="section-4.1-4.2.2">
              <dt pn="section-4.1-4.2.2.1">unknown:</dt>
              <dd pn="section-4.1-4.2.2.2">
            An S/MIME message, but it was neither signed nor encrypted.
            This can also be returned for a multipart/signed message that
            contains an unrecognized signing protocol (for example, OpenPGP).
          </dd>
              <dt pn="section-4.1-4.2.2.3">signed:</dt>
              <dd pn="section-4.1-4.2.2.4">
            An S/MIME signed message, but the signature was not yet
            verified.  Some servers might not attempt to verify a signature
            until a particular message is requested by the client.
            (This is a useful optimization for a JMAP server to avoid doing work until exact
	    information is needed.
            A JMAP client that only needs to display an icon that signifies presence of an
	    S/MIME signature can still use this value.)
            JMAP servers compliant with this document <bcp14>SHOULD</bcp14> attempt signature
	    verification
            and return "signed/verified" or "signed/failed" instead of this signature
            status.
          </dd>
              <dt pn="section-4.1-4.2.2.5">signed/verified:</dt>
              <dd pn="section-4.1-4.2.2.6">
            An S/MIME signed message, and the sender's signature
            was successfully verified according to
            <xref target="RFC8551" format="default" sectionFormat="of" derivedContent="RFC8551"/> and <xref target="RFC8550" format="default" sectionFormat="of" derivedContent="RFC8550"/>. 
            Additionally, the signer email address extracted from the S/MIME
            certificate matches the From header field value, and
            the signer certificate <bcp14>SHOULD</bcp14> be checked for revocation.
          </dd>
              <dt pn="section-4.1-4.2.2.7">signed/failed:</dt>
              <dd pn="section-4.1-4.2.2.8">
            S/MIME signed message, but the signature failed to
            verify according to <xref target="RFC8551" format="default" sectionFormat="of" derivedContent="RFC8551"/> and <xref target="RFC8550" format="default" sectionFormat="of" derivedContent="RFC8550"/>.
            This might be because of a policy-related decision (e.g., the message signer
	    email address
            doesn't match the From header field value), the message was modified,
            the signer's certificate has expired or was revoked, etc.
          </dd>
              <dt pn="section-4.1-4.2.2.9">encrypted+signed/verified:</dt>
              <dd pn="section-4.1-4.2.2.10">
            This value is reserved for future use. It is typically handled in the same way as "signed/verified".
          </dd>
              <dt pn="section-4.1-4.2.2.11">encrypted+signed/failed:</dt>
              <dd pn="section-4.1-4.2.2.12">
            This value is reserved for future use. It is typically handled in the same way as "signed/failed".
          </dd>
            </dl>
          </dd>
        </dl>
        <t indent="0" pn="section-4.1-5">The "smimeStatusAtDelivery" response property
      has the same syntax as "smimeStatus" but is calculated in relationship to the "receivedAt"
      date/time.
      Unlike "smimeStatus", the "smimeStatusAtDelivery" response property
      value doesn't change unless trust anchors are added. (For example, addition of a trust anchor
      can change the value of a message "smimeStatusAtDelivery" property from "signed/failed"
      to "signed/verified". Note that trust anchor removal doesn't affect this response property.)
      The "smimeStatusAtDelivery" response property value allows clients to compare the S/MIME
      signature verification status at delivery with the current status as returned
      by "smimeStatus", for example, to help to answer questions like
      "was the signature valid at the time of delivery?".
        </t>
        <t indent="0" pn="section-4.1-6">Note that the "smimeStatusAtDelivery" response property
      value doesn't have to be calculated at delivery time. A JMAP server
      can defer its calculation until it is explicitly requested;
      however, once it is calculated, its value is remembered for later use.
        </t>
        <t indent="0" pn="section-4.1-7">The "smimeErrors" response property is defined as follows:</t>
        <dl newline="true" spacing="normal" indent="3" pn="section-4.1-8">
          <dt pn="section-4.1-8.1"><strong>smimeErrors</strong>:</dt>
          <dd pn="section-4.1-8.2">"String[]|null" (server-set). null signifies that the message doesn't
        contain any signature or that there were no errors when verifying
        the S/MIME signature. (That is, this property is non-null only
        when the corresponding "smimeStatus" response property value
        is "signed/failed" or "encrypted+signed/failed".
	Note that future extensions to this document
        can specify other "smimeStatus" values that can be used with "smimeErrors".)
        Each string in the array is a human-readable description
        (in the language specified in the Content-Language header field, if any)
        of a problem with the signature, the signing certificate, or the signing certificate
	chain.
        (See <xref target="RFC8620" section="3.8" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8620#section-3.8" derivedContent="RFC8620"/> in regards to how this
	is affected
        by the language selection.)
        In one example, the signing certificate might be expired
        and the message From email address might not correspond to any of the email
        addresses in the signing certificate.
        In another example, the certificate might be expired and the JMAP server might
	be unable
        to retrieve a Certificate Revocation List (CRL) for the certificate.
        In both of these cases, there would be 2 elements in the array.
          </dd>
        </dl>
        <t indent="0" pn="section-4.1-9">The "smimeVerifiedAt" response property is defined as follows:</t>
        <dl newline="true" spacing="normal" indent="3" pn="section-4.1-10">
          <dt pn="section-4.1-10.1"><strong>smimeVerifiedAt</strong>:</dt>
          <dd pn="section-4.1-10.2">"UTCDate|null" (server-set). null signifies that the message doesn't
        contain any S/MIME signature or that there is a signature, but there was no attempt
        to verify it.
        (Retrieval of the "smimeStatus" value can be used to distinguish these 2 cases).
        In all other cases, it is set to the date and time of when the S/MIME signature
        was most recently verified.
        Note that a request to fetch "smimeStatus", "smimeStatusAtDelivery", and/or "smimeErrors" would force this response
        property to be set to a non-null value if an S/MIME signature exists.
          </dd>
        </dl>
        <t indent="0" pn="section-4.1-11">The "smimeStatus" and "smimeErrors" values are calculated at the time the
	corresponding JMAP	
      request is processed (but see below about the effect of result caching),
      not at the time when the message is generated (according to its
      Date header field value). In all cases, "smimeVerifiedAt" is set to the time when
      "smimeStatus" and "smimeErrors" were last updated.
      As recalculating these values is expensive for the server,
      they <bcp14>MAY</bcp14> be cached for up to 24 hours from the moment when they were calculated.
        </t>
        <t keepWithNext="true" indent="0" pn="section-4.1-12">
        Example 1: Retrieval of minimal information about a message, including its From, Subject, and Date header fields,
        as well as the S/MIME signature verification status at delivery and date/time when the message was received.
</t>
        <sourcecode name="" type="" markers="false" pn="section-4.1-13">
["Email/get", {
"ids": [ "fe123u457" ],
"properties": [ "mailboxIds", "from", "subject", "date",
 "smimeStatusAtDelivery", "receivedAt" ]
}, "#1"]
</sourcecode>
        <t indent="0" pn="section-4.1-14">This might result in the following response:</t>
        <sourcecode name="" type="" markers="false" pn="section-4.1-15">
[["Email/get", {
   "accountId": "abc",
   "state": "51234123231",
   "list": [
     {
       "id": "fe123u457",
       "mailboxIds": { "f123": true },
       "from": [{"name": "Joe Bloggs",
               "email": "joe@bloggs.example.net"}],
       "subject": "Dinner tonight?",
       "date": "2020-07-07T14:12:00Z",
       "smimeStatusAtDelivery": "signed/verified",
       "receivedAt": "2020-07-07T14:15:18Z"
     }
   ]
}, "#1"]]
</sourcecode>
        <t keepWithNext="true" indent="0" pn="section-4.1-16">
        Example 2: Retrieval of minimal information about a message, including its From, Subject, and Date header fields,
        as well as the latest S/MIME signature verification status, S/MIME verification errors (if any), and
        when the S/MIME signature status was last verified.
        The response contains 2 S/MIME errors related to S/MIME signature verification.
        </t>
        <sourcecode name="" type="" markers="false" pn="section-4.1-17">
["Email/get", {
"ids": [ "ag123u123" ],
"properties": [ "mailboxIds", "from", "subject", "date",
 "smimeStatus", "smimeErrors", "smimeVerifiedAt" ]
}, "#1"]
</sourcecode>
        <t indent="0" pn="section-4.1-18">This might result in the following response:</t>
        <sourcecode name="" type="" markers="false" pn="section-4.1-19">
[["Email/get", {
   "accountId": "abc",
   "state": "47234123231",
   "list": [
     {
       "id": "ag123u123",
       "mailboxIds": { "f123": true },
       "from": [{"name": "Jane Doe",
               "email": "jdoe@example.com"}],
       "subject": "Company takeover",
       "date": "2020-01-31T23:00:00Z",
       "smimeStatus": "signed/failed",
       "smimeErrors": [
         "From email address doesn't match the certificate",
         "Can't retrieve CRL from the CRL URL"],
       "smimeVerifiedAt": "2020-03-01T12:11:19Z"
     }
   ]
}, "#1"]]
</sourcecode>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1.1">
          <name slugifiedName="name-smimestatus-response-proper">"smimeStatus" Response Property Extensibility</name>
          <t indent="0" pn="section-4.1.1-1">
          Future extensions to this document can specify extra allowed values for the "smimeStatus" response property.
          All values (defined in this document or in extensions to this document) <bcp14>MUST</bcp14> be in ASCII.
          (Note that this response property contains tokens; thus, it is not subject to
          internationalization or localization).          
          </t>
          <t indent="0" pn="section-4.1.1-2">
          New "smimeStatus" response property values defined in extensions may affect the behavior of
          properties, such as the "smimeErrors" response property of Email/get (see <xref target="email-get-ext" format="default" sectionFormat="of" derivedContent="Section 4.1"/>) or the
          "hasVerifiedSmime" property of Email/query (see <xref target="email-query-ext" format="default" sectionFormat="of" derivedContent="Section 4.2"/>). In particular,
          the new values can be treated similarly to values defined in this document.
          </t>
          <t indent="0" pn="section-4.1.1-3">
          For example, a putative JMAP extension for automatically decrypting S/MIME messages can specify
          two additional values, one specifying that a message is both encrypted and signed with a valid S/MIME signature
          (e.g. "encrypted+signed/verified")
          and another one specifying that a message is both encrypted and signed with an invalid S/MIME signature
          (e.g. "encrypted+signed/failed").
          The former value can be treated as "signed/verified" (and would thus affect "hasVerifiedSmime")
          and the latter can be treated as "signed/failed" (and thus can be used with "smimeErrors").
          </t>
        </section>
      </section>
      <section anchor="email-query-ext" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-extension-to-email-query">Extension to Email/query</name>
        <t indent="0" pn="section-4.2-1">
        <xref target="RFC8621" format="default" sectionFormat="of" derivedContent="RFC8621"/> defines the Email/query method for searching for messages with specific properties.
        This document defines the following properties of the <strong>FilterCondition</strong> object:

        </t>
        <dl newline="true" spacing="normal" indent="3" pn="section-4.2-2">
          <dt pn="section-4.2-2.1"><strong>hasSmime</strong>:</dt>
          <dd pn="section-4.2-2.2">"Boolean". If "hasSmime" has the value true, only messages with "smimeStatus"
	  other than null match the condition.
          If "hasSmime" has the value false, only messages with "smimeStatus" equal to null
	  match the condition.</dd>
          <dt pn="section-4.2-2.3"><strong>hasVerifiedSmime</strong>:</dt>
          <dd pn="section-4.2-2.4">
            <t indent="0" pn="section-4.2-2.4.1">"Boolean". If "hasVerifiedSmime" has the value true, only messages with
	  "smimeStatus" equal
          to "signed/verified" or "encrypted+signed/verified" (*) match the condition.
          If "hasVerifiedSmime" has the value false, only messages with "smimeStatus" not
	  equal
          to "signed/verified" and not equal to "encrypted+signed/verified" (*) (including
	  the value null) match the condition.
          Note that use of this attribute is potentially expensive for a JMAP server, as it
	  forces
          calculation of the "smimeStatus" property value for each message. However, caching of the 
	  "smimeStatus"
          values should ameliorate this cost somewhat.</t>
            <t indent="0" pn="section-4.2-2.4.2">
          (*) as well as the "smimeStatus" values added by future extensions to this document
          that are explicitly specified as having similar effect to "signed/verified" as far
	  as
          "hasVerifiedSmime" calculation is concerned.</t>
          </dd>
          <dt pn="section-4.2-2.5"><strong>hasVerifiedSmimeAtDelivery</strong>:</dt>
          <dd pn="section-4.2-2.6">"Boolean". The "hasVerifiedSmimeAtDelivery" property is handled similarly to
	  the "hasVerifiedSmime" property,
          but the value of "smimeStatusAtDelivery" is used instead of "smimeStatus" to assess
          whether a particular message matches the condition.
          </dd>
        </dl>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-interaction-with-email-chan">Interaction with Email/changes</name>
        <t indent="0" pn="section-4.3-1">Changes to the "smimeVerifiedAt" response property value <bcp14>MUST NOT</bcp14>
        cause the message to be included in the "updated" argument of the Email/changes response.
        However, changes to the "smimeStatus", "smimeStatusAtDelivery", and/or "smimeErrors"
        response properties <bcp14>MUST</bcp14> result in message inclusion in the "updated" argument of the
	Email/changes response.
        </t>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-jmap-capability-registratio">JMAP Capability Registration for "smimeverify"</name>
        <t indent="0" pn="section-5.1-1">
          IANA has registered the "smimeverify" JMAP capability as follows:
        </t>
        <dl newline="false" spacing="compact" indent="3" pn="section-5.1-2">
          <dt pn="section-5.1-2.1">Capability Name:</dt>
          <dd pn="section-5.1-2.2">urn:ietf:params:jmap:smimeverify</dd>
          <dt pn="section-5.1-2.3">Specification document:</dt>
          <dd pn="section-5.1-2.4">RFC 9219</dd>
          <dt pn="section-5.1-2.5">Intended use:</dt>
          <dd pn="section-5.1-2.6">common</dd>
          <dt pn="section-5.1-2.7">Change Controller:</dt>
          <dd pn="section-5.1-2.8">IETF</dd>
          <dt pn="section-5.1-2.9">Security and privacy considerations:</dt>
          <dd pn="section-5.1-2.10">RFC 9219, <xref target="seccons" format="default" sectionFormat="of" derivedContent="Section 6"/></dd>
        </dl>
      </section>
    </section>
    <section anchor="seccons" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-6-1">
      Use of the server-side S/MIME signature verification JMAP extension requires
      the client to trust the server signature verification code, the server configuration, and
      the server's operational practices
      to perform S/MIME signature verification, as well as to trust that the channel between
      the client and the server is integrity protected.
      (For example, if the server is not configured
      with some trust anchors, some messages will have the "signed/failed" status
      instead of "signed/verified".)
      A malicious or compromised server could
      return a false verification status to a client.  A successful verification could
      be conveyed to a client for a forged or altered message.  A properly signed
      message could be signaled as having a failed signature verification or no
      signature at all.  In the case of the latter attack, no new attack surface is
      presented with this extension above what a malicious or compromised server could
      already do by stripping or tampering with the S/MIME information in the
      message.  In the case of the former attack, client software capable of
      performing S/MIME signature verification could detect this attack.  Local
      configuration of the client should determine if this client-side verification
      should occur.  For clients without local verification capabilities, such an
      attack would be difficult to detect.
      </t>
      <t indent="0" pn="section-6-2">
      Integrity protection of the channel between the client and the server is provided by use of TLS,
      as required by the JMAP specification (see <xref target="RFC8620" section="8.1" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8620#section-8.1" derivedContent="RFC8620"/>).
      </t>
      <t indent="0" pn="section-6-3">Constant recalculation of the S/MIME signature status can result in a denial-of-service condition.
      For that reason, it is <bcp14>RECOMMENDED</bcp14> that servers cache results of signature verification for up to 24 hours.</t>
    </section>
  </middle>
  <back>
    <references pn="section-7">
      <name slugifiedName="name-references">References</name>
      <references pn="section-7.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5280" quoteTitle="true" derivedAnchor="RFC5280">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
            <author initials="D." surname="Cooper" fullname="D. Cooper">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Santesson" fullname="S. Santesson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Farrell" fullname="S. Farrell">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Boeyen" fullname="S. Boeyen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Housley" fullname="R. Housley">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="W." surname="Polk" fullname="W. Polk">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="May"/>
            <abstract>
              <t indent="0">This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet.  An overview of this approach and model is provided as an introduction.  The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms.  Standard certificate extensions are described and two Internet-specific extensions are defined.  A set of required certificate extensions is specified.  The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions.  An algorithm for X.509 certification path validation is described.  An ASN.1 module and examples are provided in the appendices.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5280"/>
          <seriesInfo name="DOI" value="10.17487/RFC5280"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8550" target="https://www.rfc-editor.org/info/rfc8550" quoteTitle="true" derivedAnchor="RFC8550">
          <front>
            <title>Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling</title>
            <author initials="J." surname="Schaad" fullname="J. Schaad">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Ramsdell" fullname="B. Ramsdell">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Turner" fullname="S. Turner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2019" month="April"/>
            <abstract>
              <t indent="0">This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280 ("Internet X.509 Public Key Infrastructure Certificate and                                     Certificate Revocation List (CRL) Profile").  S/MIME agents must meet the certificate-processing requirements in this document as well as those in RFC 5280.  This document obsoletes RFC 5750.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8550"/>
          <seriesInfo name="DOI" value="10.17487/RFC8550"/>
        </reference>
        <reference anchor="RFC8551" target="https://www.rfc-editor.org/info/rfc8551" quoteTitle="true" derivedAnchor="RFC8551">
          <front>
            <title>Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification</title>
            <author initials="J." surname="Schaad" fullname="J. Schaad">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Ramsdell" fullname="B. Ramsdell">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Turner" fullname="S. Turner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2019" month="April"/>
            <abstract>
              <t indent="0">This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0.  S/MIME provides a consistent way to send and receive secure MIME data.  Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality.  Compression can be used to reduce data size.  This document obsoletes RFC 5751.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8551"/>
          <seriesInfo name="DOI" value="10.17487/RFC8551"/>
        </reference>
        <reference anchor="RFC8620" target="https://www.rfc-editor.org/info/rfc8620" quoteTitle="true" derivedAnchor="RFC8620">
          <front>
            <title>The JSON Meta Application Protocol (JMAP)</title>
            <author initials="N." surname="Jenkins" fullname="N. Jenkins">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Newman" fullname="C. Newman">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2019" month="July"/>
            <abstract>
              <t indent="0">This document specifies a protocol for clients to efficiently query, fetch, and modify JSON-based data objects, with support for push notification of changes and fast resynchronisation and for out-of- band binary data upload/download.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8620"/>
          <seriesInfo name="DOI" value="10.17487/RFC8620"/>
        </reference>
        <reference anchor="RFC8621" target="https://www.rfc-editor.org/info/rfc8621" quoteTitle="true" derivedAnchor="RFC8621">
          <front>
            <title>The JSON Meta Application Protocol (JMAP) for Mail</title>
            <author initials="N." surname="Jenkins" fullname="N. Jenkins">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Newman" fullname="C. Newman">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2019" month="August"/>
            <abstract>
              <t indent="0">This document specifies a data model for synchronising email data with a server using the JSON Meta Application Protocol (JMAP). Clients can use this to efficiently search, access, organise, and send messages, and to get push notifications for fast resynchronisation when new messages are delivered or a change is made in another client.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8621"/>
          <seriesInfo name="DOI" value="10.17487/RFC8621"/>
        </reference>
      </references>
      <references pn="section-7.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC1847" target="https://www.rfc-editor.org/info/rfc1847" quoteTitle="true" derivedAnchor="RFC1847">
          <front>
            <title>Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted</title>
            <author initials="J." surname="Galvin" fullname="J. Galvin">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Murphy" fullname="S. Murphy">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Crocker" fullname="S. Crocker">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N." surname="Freed" fullname="N. Freed">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1995" month="October"/>
            <abstract>
              <t indent="0">This document defines a framework within which security services may be applied to MIME body parts.  [STANDARDS-TRACK] This memo defines a new Simple Mail Transfer Protocol (SMTP) [1] reply code, 521, which one may use to indicate that an Internet host does not accept incoming mail.  This memo defines an Experimental Protocol for the Internet community. This memo defines an extension to the SMTP service whereby an interrupted SMTP transaction can be restarted at a later time without having to repeat all of the commands and message content sent prior to the interruption.  This memo defines an Experimental Protocol for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1847"/>
          <seriesInfo name="DOI" value="10.17487/RFC1847"/>
        </reference>
      </references>
    </references>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">This document is a product of the JMAP Working Group.
      Special thank you to <contact fullname="Bron Gondwana"/>, <contact fullname="Neil       Jenkins"/>, <contact fullname="Murray Kucherawy"/>, <contact fullname="Kirsty Paine"/>,
      <contact fullname="Benjamin Kaduk"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Peter Yee"/>, <contact fullname="Robert Wilton"/>,
      <contact fullname="Erik Kline"/>, and <contact fullname="Menachem Dodge"/> for
      suggestions, comments, and corrections to this document.
      </t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-address">Author's Address</name>
      <author initials="A." surname="Melnikov" fullname="Alexey Melnikov">
        <organization showOnFrontPage="true">Isode Ltd</organization>
        <address>
          <postal>
            <street>14 Castle Mews</street>
            <city>Hampton, Middlesex</city>
            <code>TW12 2NP</code>
            <country>United Kingdom</country>
          </postal>
          <email>Alexey.Melnikov@isode.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
