<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>

<rfc ipr="trust200902" category="info" docName='draft-ietf-jmap-smime-sender-extensions-01'>
  <front>
    <title abbrev="JMAP extension for S/MIME">
      JMAP extension for S/MIME signing and encryption
    </title>
    <author initials="A." surname="Melnikov" fullname="Alexey Melnikov">
      <organization>Isode Ltd</organization>
      <address>
        <postal>
          <street>14 Castle Mews</street>
          <city>Hampton</city>
          <region>Middlesex</region>
          <code>TW12 2NP</code>
          <country>UK</country>
        </postal>
        <email>Alexey.Melnikov@isode.com</email>
      </address>
    </author>
      
    <date year="2021" />
    
    <keyword>JMAP</keyword>
    <keyword>S/MIME</keyword>

    <abstract>

    <t>
    This document specifies an extension to JMAP for sending S/MIME signed and S/MIME encrypted messages<!--, and automatic decryption of received S/MIME messages-->.
    </t>
	
    </abstract>
    
  </front>
  <middle>

    <section title="Introduction">

        <t>
        <xref target="RFC8621"/> is a JSON based application protocol for synchronising email data
        between a client and a server.

<!--
   JMAP [RFC8620] is a generic protocol for synchronising
   data, such as mail, calendars or contacts, between a client and a
   server.  It is optimised for mobile and web environments, and aims to
   provide a consistent interface to different data types.
   [RFC8621] builds on top of JMAP and defines how to perform
   email synchronization.
-->
        </t>
      
        <t>
        This document describes an extension to JMAP for sending S/MIME signed and encrypted messages
        <!--, and automatic decryption of received S/MIME messages-->.
        It allows JMAP server to <!--access (preconfigured) user's signing and encryption keys, and-->
        sign/encrypt messages on user's behalf.
        </t>

    </section>
    
    <section title="Conventions Used in This Document">
      
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
	    this document are to be interpreted as described in
	    <xref target="RFC2119"/>.</t>

    </section>

    <section title="Addition to the capabilities object">

      <t>
        The capabilities object is returned as part of the standard JMAP
        Session object; see the JMAP spec.  Servers supporting _this_
        specification MUST add a property called
        "urn:ietf:params:jmap:smime-advanced" to the capabilities object.
      </t>

      <t>
        <!--/////This might change in the future if S/MIME signing/encrypting/decrypting is added:-->
        The value of this property is an empty object in both the JMAP
        session _capabilities_ property and an account's
        _accountCapabilities_ property.
      </t>

    </section>

    <section title="Extension to Email/set for S/MIME signing and/or encryption" anchor="smime">

      <!--The following assumes that messages created signed/encrypted, when they are created and uploaded.
      I.e. this operation is not deferred till later Send. Is this the right model?-->

      <t>
        <xref target="RFC8621"/> defines Email/set method for creating new email messages.
        This document defines the following additional request arguments that can be used to
        create S/MIME signed and/or encrypted messages:<vspace/>

        <list style="bullets">

          <t>
            smimeSign: "Boolean" (default: false). If included and has the value "true", this requests the JMAP server
            to create an S/MIME signed message from the message constructed according to other specified arguments (the "original message").
            This is done by encapsulating the original message either inside application/pkcs7-mime or
            multipart/signed container. <!--///Add references--> <!--///Do we need a way to control which type of encapsulation is to be used?-->
            The signature's private key/certificate is associated with the email address in
            the Sender header field, if present; otherwise, it is associated with the email address
            in the From header field, if present.<vspace/>

            If multiple addresses are present in one of these header
            fields, or there is more than one Sender/From header field, the
            server SHOULD reject the Email/set as invalid<!--///Add new error code?-->; otherwise,
            it MUST take the first address in the last Sender/From header field.
          </t>

          <t>
            smimeEncrypt: "Boolean" (default: false). If included and has the value "true", this requests the JMAP server
            to create an S/MIME encrypted message from the constructed message.
            This is done by encapsulating the message inside application/pkcs7-mime media type.
            The message MUST be encrypted to the sender and all To/Cc/Bcc recipients.
            This extension assumes that there is some kind of per user or organizational addressbook,
            that can be used to lookup public keys of recipients. If lookup of a particular public key fails,
            or results in an expired or revoked certificate, the Email/set operation MUST fail.<!--Add new error code?-->
          </t>

        </list>
      </t>

      <t>
      If both "smimeSign" and "smimeEncrypt" are set to true, the message is first signed and then the signed version is encrypted (in that order).
      </t>

      <t>
        <!--///Use <aside>?-->
        (Note that this extension doesn't allow management of private keys/certificates.
        How private keys are managed or configured for a particular user is out of scope for this document.)
      </t>

      <t>
      [[How to control header protection?]]
      </t>
      
      
      <!--///For decryption: should we return blobIds for decrypted body parts and let clients use Email/parse on them?-->

      <figure title="Example 1:">
        <preamble>
        </preamble>
<artwork>
  <![CDATA[
      [[ "Email/set", {
        "accountId": "ue150411c",
        "create": {
          "k192": {
            "mailboxIds": {
              "2ea1ca41b38e": true
            },
            "keywords": {
              "$seen": true,
              "$draft": true
            },
            "from": [{
              "name": "Joe Bloggs",
              "email": "joe@example.com"
            }],
            "subject": "World domination",
            "receivedAt": "2021-07-07T01:03:11Z",
            "sentAt": "2021-07-10T11:03:11+10:00",
            "smimeSign": true,
            "smimeEncrypt": true,
            "bodyStructure": {
              "type": "text/plain",
              "partId": "bd48",
              "header:Content-Language": "en"
            },
            "bodyValues": {
              "bd48": {
                "value": "I have the most brilliant plan.  Let me tell
                  you all about it.",
                "isTruncated": false
              }
            }
          }
        }
      }, "0" ]]

This will result in the following response:

      [[ "Email/set", {
        "accountId": "ue150411c",
        "oldState": "780823",
        "newState": "780839",
        "created": {
          "k192": {
            "id": "Mf40b5f831efa7233b9eb1c7f",
            "blobId": "Gf40b5f831efa7233b9eb1c7f8f97d84eeeee64f7",
            "threadId": "Td957e72e89f516dc",
            "size": 5096
          }
        },
        ...
      }, "0" ]]
]]></artwork>
        <postamble>
        </postamble>
      </figure>

<!--      
      <figure title="Example 2:">
        <preamble>
        </preamble>
<artwork><![CDATA[
      ["Email/get", {
      "ids": [ "af123u123" ],
      "properties": [ "mailboxIds", "from", "subject", "date",
       "smimeStatus", "smimeErrors", "smimeVerifiedAt" ]
      }, "#1"]
      
This will result in the following response:

      [["Email/get", {
         "accountId": "abc",
         "state": "41234123231",
         "list": [
           {
             id: "af123u123",
             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"]]
]]></artwork>
        <postamble>
        </postamble>
      </figure>
-->

    </section>

    <section title="IANA Considerations">

      <section title='JMAP capability registration for "smime-advanced"'>

        <t>
          IANA is requested to register the "smime" JMAP Capability as follows:
        </t>

        <t>
          Capability Name: "urn:ietf:params:jmap:smime-advanced"
        </t>

        <t>
          Specification document: this document
        </t>

        <t>
          Intended use: common
        </t>

        <t>
          Change Controller: IETF
        </t>

        <t>
          Security and privacy considerations: this document, <xref target="seccons"/>
        </t>

      </section>
      
    </section>

    <section title="Security Considerations" anchor="seccons">

      <t>This JMAP extension assumes trust between the user and the JMAP server for purposes of signing and encrypting messages on user's behalf.
      <!--This might break "end-to-end encrypted" guarantee that might be expected from use of S/MIME.-->
      </t>
      
      <t>This JMAP extension also relies on access to user's (or organization's) addressbook which contain up-to-date certificates for recipients.
      </t>

      <t>This JMAP extension doesn't support management of user's private keys and corresponding certificates.</t>

      <!--
      <t>TBD. Server that lies?</t>
      -->

    </section>
    
  </middle>
  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?> <!-- Keywords -->
      <?rfc include="reference.RFC.8550"?> <!-- S/MIME Certificate Handling -->
      <?rfc include="reference.RFC.8551"?> <!-- S/MIME Message Format -->
      <?rfc include="reference.RFC.8620"?> <!-- JMAP Core -->
      <?rfc include="reference.RFC.8621"?> <!-- JMAP Mail -->      
    </references>

<!--    
    <references title="Informative References">
    </references>
-->

<!--
    <section title="Acknowledgements">
	
      <t>Thank you to Steve Kille and David Wilson for suggestions, comments and corrections on this document.</t>

      <t>David Wilson came up with the idea of defining a new Content-Type header field parameter to distinguish
      forwarded messages from inner header field protection constructs.</t>
      
    </section>
-->    
    
  </back>
</rfc>
