<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?> [
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" submissionType="IETF" category="std" docName='draft-ietf-jmap-smime-12'> consensus="true" docName="draft-ietf-jmap-smime-12" number="9219" obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.12.0 -->
<front>
<title abbrev="JMAP extension Extension for S/MIME">
S/MIME signature verification extension Signature Verification Extension to JMAP the JSON Meta Application Protocol
(JMAP)
</title>
<seriesInfo name="RFC" value="9219"/>
<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>
<city>Hampton, Middlesex</city>
<code>TW12 2NP</code>
<country>UK</country>
<country>United Kingdom</country>
</postal>
<email>Alexey.Melnikov@isode.com</email>
</address>
</author>
<date year="2022" month="March" />
<keyword>JMAP</keyword>
<keyword>S/MIME</keyword>
<abstract>
<t>
This document specifies an extension to JMAP "The JSON Meta Application Protocol
(JMAP) for Mail Mail" (RFC 8621) for returning the S/MIME signature verification status.
</t>
</abstract>
</front>
<middle>
<section title="Introduction"> numbered="true" toc="default">
<name>Introduction</name>
<t>
<xref target="RFC8621">JMAP target="RFC8621" format="default">JMAP for Mail</xref> is a JSON-based application protocol for synchronising synchronizing 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 returning the S/MIME <xref target="RFC8551"/>
signature verification status, status <xref target="RFC8551"
format="default"/>, 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"/> target="RFC1847" format="default"/>
is used) or to download and decode CMS the Cryptographic Message Syntax (CMS)
(when the application/pkcs7-mime media type (Section 3.2 of <xref target="RFC8551"/>) (<xref target="RFC8551"
section="3.2" sectionFormat="of" format="default"/>) 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 title="Conventions numbered="true" toc="default">
<name>Conventions Used in This Document"> Document</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<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 "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in
BCP 14 <xref target="RFC2119"/> target="RFC2119" format="default"/> <xref target="RFC8174"/> target="RFC8174" format="default"/> when, and only when, they
appear in all capitals, as shown here.
</t>
<t>
Type signatures, examples, and property descriptions in this document
follow the conventions established in Section 1.1 of <xref target="RFC8620"/>. target="RFC8620" section="1.1" sectionFormat="of" format="default"/>.
Data types defined in the core specification are also used in this document.
</t>
</section>
<section title="Addition numbered="true" toc="default">
<name>Addition to the capabilities object"> Capabilities Object</name>
<t>
The capabilities <strong>capabilities</strong> object is returned as part of the standard JMAP
Session object; see Section 2 of <xref target="RFC8620"/>. target="RFC8620" section="2" sectionFormat="of" format="default"/>.
Servers supporting _this_ this
specification MUST <bcp14>MUST</bcp14> add a property called
"urn:ietf:params:jmap:smimeverify" to the capabilities object.
</t>
<t>
The value of this property is an empty object in both the JMAP
session _capabilities_
Session <em>capabilities</em> property and an account's
_accountCapabilities_
<em>accountCapabilities</em> property.
</t>
</section>
<section title="Extension anchor="smime" numbered="true" toc="default">
<name>Extension for S/MIME signature verification" anchor="smime"> Signature Verification</name>
<section title="Extension anchor="email-get-ext" numbered="true" toc="default">
<name>Extension to Email/get" anchor="email-get-ext"> Email/get</name>
<t>
<xref target="RFC8621"/> target="RFC8621" format="default"/> defines the Email/get method for retrieving message specific message-specific information.
This document defines the following pseudo values in the _properties_ argument:<vspace/>
<list style="bullets">
<t>*smimeStatus*: If <em>properties</em> argument:</t>
<dl newline="true" spacing="normal">
<dt><strong>smimeStatus</strong>:</dt>
<dd>If "smimeStatus" is included in the list of requested
properties, it MUST <bcp14>MUST</bcp14> be interpreted by the server as a request to
return the "smimeStatus" response property.</t>
<t>*smimeStatusAtDelivery*: If property.</dd>
<dt><strong>smimeStatusAtDelivery</strong>:</dt>
<dd>If "smimeStatusAtDelivery" is included in the list of requested
properties, it MUST <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".)</t>
<t>*smimeErrors*: If "receivedAt".)</dd>
<dt><strong>smimeErrors</strong>:</dt>
<dd>If "smimeErrors" is included in the list of requested
properties, it MUST <bcp14>MUST</bcp14> be interpreted by the server as a request to
return the "smimeErrors" response property.</t>
<!--///Rename "smimeVerifiedAt" to "smimeValidatedAt" everywhere?-->
<t>*smimeVerifiedAt*: If property.</dd>
<dt><strong>smimeVerifiedAt</strong>:</dt>
<dd>If "smimeVerifiedAt" is included in the list of requested
properties, it MUST <bcp14>MUST</bcp14> be interpreted by the server as a request to
return the "smimeVerifiedAt" response property.</t>
</list>
</t> property.</dd>
</dl>
<t>The "smimeStatus" response property is defined as follows:</t>
<t>
smimeStatus: "String|null"
<dl newline="true" spacing="normal">
<dt><strong>smimeStatus</strong>:</dt>
<dd><t>"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"/> target="RFC8551" format="default"/>, <xref target="RFC8550" format="default"/>, and <xref target="RFC8550"/><!--and RFC 5280 that the latter depends on -->. target="RFC5280" format="default"/>.
Possible string values of the property are
listed below. Servers MAY <bcp14>MAY</bcp14> return other values not defined below,
as defined in extensions to this document.
<!--///Alexey (based on feedback from Murray): maybe just use "unknown" and clarify that some will treat
"unknown" as "signed/failed" for security reasons?-->
Clients MUST <bcp14>MUST</bcp14> treat unrecognized values as "unknown" or "signed/failed".
Note that the value of this property might change over time.
<list style="hanging">
<t hangText="unknown:"> time.</t>
<dl newline="true" spacing="normal">
<dt>unknown:</dt>
<dd>
An S/MIME message, but it was neither signed nor encrypted.
This can also be returned for a multipart/signed message which that
contains an unrecognized signing protocol (for example example, OpenPGP).
</t>
<t hangText="signed:">
</dd>
<dt>signed:</dt>
<dd>
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 SHOULD <bcp14>SHOULD</bcp14> attempt signature
verification
and return "signed/verified" or "signed/failed" instead of this signature
status.
</t>
<t hangText="signed/verified:">
</dd>
<dt>signed/verified:</dt>
<dd>
An S/MIME signed message message, and the sender's signature
was successfully verified according to
<xref target="RFC8551"/> target="RFC8551" format="default"/> and <xref target="RFC8550"/>.
Additionally target="RFC8550"
format="default"/>.
Additionally, the signer email address extracted from the S/MIME
certificate matches the From header field value, and
the signer certificate SHOULD <bcp14>SHOULD</bcp14> be checked for revocation.
</t>
<t hangText="signed/failed:">
</dd>
<dt>signed/failed:</dt>
<dd>
S/MIME signed message, but the signature failed to
verify according to <xref target="RFC8551"/> target="RFC8551" format="default"/> and <xref target="RFC8550"/>.
target="RFC8550" format="default"/>.
This might be because of a policy related policy-related decision (e.g. (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.
</t>
<t hangText="encrypted+signed/verified:">
</dd>
<dt>encrypted+signed/verified:</dt>
<dd>
This value is reserved for future use. It is typically handled in the same way as "signed/verified".
</t>
<t hangText="encrypted+signed/failed:">
</dd>
<dt>encrypted+signed/failed:</dt>
<dd>
This value is reserved for future use. It is typically handled in the same way as "signed/failed".
</t>
</list>
</t>
</dd>
</dl>
</dd>
</dl>
<t>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, change unless Trust Anchors trust anchors are added. (For example, addition of a Trust Anchor trust anchor
can change the value of a message "smimeStatusAtDelivery" property from "signed/failed"
to "signed/verified". Note that Trust Anchor 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 example, to help to answer questions like
"was the signature valid at the time of delivery?".
</t>
<t>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,
but requested;
however, once calculated it is calculated, its value is remembered for later use.
</t>
<t>The "smimeErrors" response property is defined as follows:</t>
<t>
smimeErrors: "String[]|null"
<dl newline="true" spacing="normal">
<dt><strong>smimeErrors</strong>:</dt>
<dd>"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. (I.e., (That is, this property is non null 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 "smimeStatus" values that can be used with smimeErrors.) "smimeErrors".)
Each string in the array is a human readable human-readable description
(in the language specified in the Content-Language header field, if any)
of a problem with the signature, the signing certificate certificate, or the signing certificate
chain.
(See Section 3.8 of <xref target="RFC8620"/> target="RFC8620" section="3.8" sectionFormat="of" format="default"/> 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 example, the certificate might be expired and the JMAP server might
be unable
to retrieve a CRL Certificate Revocation List (CRL) for the certificate.
In both of these cases cases, there would be 2 elements in the array.
</t>
</dd>
</dl>
<t>The "smimeVerifiedAt" response property is defined as follows:</t>
<t>
smimeVerifiedAt: "UTCDate|null"
<dl newline="true" spacing="normal">
<dt><strong>smimeVerifiedAt</strong>:</dt>
<dd>"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 "smimeStatus" value can be used to distinguish these 2 cases).
In all other cases 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" "smimeStatusAtDelivery", and/or "smimeErrors" would force this response
property to be set to a non null value, non-null value if an S/MIME signature exists.
</t>
<t>"smimeStatus"
</dd>
</dl>
<t>The "smimeStatus" and "smimeErrors" values are calculated at the time the
corresponding JMAP
request was is processed (but see below about the effect of result caching),
not at the time when the message was is generated (according to its
Date header field value). In all cases cases, "smimeVerifiedAt" is set to the time when
"smimeStatus" and "smimeErrors" were last updated.
As recalculating these values is expensive for the server,
<!--This seems to be a reasonable balance between doing online CRL / OCSP checks right away
and typical expiration period for certificates.-->
they MAY <bcp14>MAY</bcp14> be cached for up to 24 hours from the moment when they were calculated.
</t>
<figure>
<preamble>
<t keepWithNext="true">
Example 1: Retrieval of minimal information about a message, including its From, Subject Subject, and Date header fields,
as well as the S/MIME signature verification status at delivery and date/time when the message was received.
</preamble>
<artwork><![CDATA[
</t>
<sourcecode name="" type=""><![CDATA[
["Email/get", {
"ids": [ "fe123u457" ],
"properties": [ "mailboxIds", "from", "subject", "date",
"smimeStatusAtDelivery", "receivedAt" ]
}, "#1"]
This
]]></sourcecode>
<t>This might result in the following response: response:</t>
<sourcecode name="" type=""><![CDATA[
[["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"]]
]]></artwork>
<postamble>
</postamble>
</figure>
<figure>
<preamble>
]]></sourcecode>
<t keepWithNext="true">
Example 2: Retrieval of minimal information about a message, including its From, Subject Subject, and Date header fields,
as well as the latest S/MIME signature verification status, S/MIME verification errors (if any) any), and
when was the S/MIME signature status was last verified.
The response contains 2 S/MIME errors related to S/MIME signature verification.
</preamble>
<artwork><![CDATA[
</t>
<sourcecode name="" type=""><![CDATA[
["Email/get", {
"ids": [ "ag123u123" ],
"properties": [ "mailboxIds", "from", "subject", "date",
"smimeStatus", "smimeErrors", "smimeVerifiedAt" ]
}, "#1"]
This
]]></sourcecode>
<t>This might result in the following response: response:</t>
<sourcecode name="" type=""><![CDATA[
[["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"]]
]]></artwork>
<postamble>
</postamble>
</figure>
]]></sourcecode>
<section title='"smimeStatus" response property extensibility'> numbered="true" toc="default">
<name>"smimeStatus" Response Property Extensibility</name>
<t>
Future extensions to this document can specify extra allowed values for the smimeStatus "smimeStatus" response property.
All values (defined in this document or in extensions to this document) MUST <bcp14>MUST</bcp14> be in ASCII.
(Note that this response property contains tokens, thus tokens; thus, it is not subject to
Internationalization
internationalization or Localization). localization).
</t>
<t>
New smimeStatus "smimeStatus" response property values defined in extensions may affect behaviour the behavior of
properties
properties, such as smimeErrors the "smimeErrors" response property of Email/get (see <xref target="email-get-ext"/>) target="email-get-ext" format="default"/>) or
hasVerifiedSmime the
"hasVerifiedSmime" property of Email/query (see <xref target="email-query-ext"/>). target="email-query-ext" format="default"/>). In particular particular,
the new values can be treated similar similarly to values defined in this document.
</t>
<t>
<!--///Should this be reworded to allow for reserved "encrypted+signed/failed" and "encrypted+signed/verified"?-->
For example 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. signature
(e.g. "encrypted+signed/failed").
The former value can be treated as "signed/verified" (and would thus affect hasVerifiedSmime) "hasVerifiedSmime")
and the latter can be treated as "signed/failed" (and thus can be used with smimeErrors). "smimeErrors").
</t>
</section>
</section>
<section title="Extension anchor="email-query-ext" numbered="true" toc="default">
<name>Extension to Email/query" anchor="email-query-ext"> Email/query</name>
<t>
<xref target="RFC8621"/> target="RFC8621" format="default"/> defines the Email/query method for searching for messages with specific properties.
This document defines the following properties of the *FilterCondition* <strong>FilterCondition</strong> object:
<list style="bullets">
<t>*hasSmime*: "Boolean".
</t>
<dl newline="true" spacing="normal">
<dt><strong>hasSmime</strong>:</dt>
<dd>"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.</t>
<t>*hasVerifiedSmime*: "Boolean". condition.</dd>
<dt><strong>hasVerifiedSmime</strong>:</dt>
<dd><t>"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 smimeStatus the "smimeStatus" property value for each message. However However, caching of smimeStatus the
"smimeStatus"
values should ameliorate this cost somewhat.<vspace/> somewhat.</t>
<t>
(*) 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>
<t>*hasVerifiedSmimeAtDelivery*: "Boolean". concerned.</t></dd>
<dt><strong>hasVerifiedSmimeAtDelivery</strong>:</dt>
<dd>"Boolean". The "hasVerifiedSmimeAtDelivery" property is handled similar similarly to
the "hasVerifiedSmime" property,
but the value of "smimeStatusAtDelivery" is used instead of "smimeStatus" to assess
whether a particular message matches the condition.
</t>
</list>
</t>
</dd>
</dl>
</section>
<section title="Interaction numbered="true" toc="default">
<name>Interaction with Email/changes"> Email/changes</name>
<t>Changes to the "smimeVerifiedAt" response property value MUST NOT <bcp14>MUST NOT</bcp14>
cause the message to be included in the "updated" argument of the Email/changes response.
However
However, changes to the "smimeStatus", "smimeStatusAtDelivery" "smimeStatusAtDelivery", and/or "smimeErrors"
response properties MUST <bcp14>MUST</bcp14> result in message inclusion in the "updated" argument of the
Email/changes response.
</t>
</section>
</section>
<section title="IANA Considerations"> numbered="true" toc="default">
<name>IANA Considerations</name>
<section title='JMAP capability registration numbered="true" toc="default">
<name>JMAP Capability Registration for "smimeverify"'> "smimeverify"</name>
<t>
IANA is requested to register has registered the "smimeverify" JMAP Capability capability as follows:
</t>
<t>
Capability Name: "urn:ietf:params:jmap:smimeverify"
</t>
<t>
Specification document: this document
</t>
<t>
Intended use: common
</t>
<t>
Change Controller: IETF
</t>
<t>
Security
<dl newline="false" spacing="compact">
<dt>Capability Name:</dt>
<dd>urn:ietf:params:jmap:smimeverify</dd>
<dt>Specification document:</dt>
<dd>RFC 9219</dd>
<dt>Intended use:</dt>
<dd>common</dd>
<dt>Change Controller:</dt>
<dd>IETF</dd>
<dt>Security and privacy considerations: this document, <xref target="seccons"/>
</t> considerations:</dt>
<dd>RFC 9219, <xref target="seccons" format="default"/></dd>
</dl>
</section>
</section>
<section title="Security Considerations" anchor="seccons"> anchor="seccons" numbered="true" toc="default">
<name>Security Considerations</name>
<t>
Use of the server-side S/MIME signature verification JMAP extension requires
the client to trust the server signature verification code, the server configuration configuration, and its
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, 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>
Integrity protection of the channel between the client and the server is provided by use of TLS,
as required by the JMAP specification (see Section 8.1 of <xref target="RFC8620"/>). target="RFC8620" section="8.1" sectionFormat="of" format="default"/>).
</t>
<t>Constant recalculation of the S/MIME signature status can result in a Denial-of-Service denial-of-service condition.
For that reason, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that servers cache results of signature verification for up to 24 hours.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?> <!-- Keywords. BCP 14, part 1. -->
<?rfc include="reference.RFC.8174"?> <!-- Keywords. BCP 14, part 2. -->
<?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>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8550.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8551.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8620.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8621.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1847.xml"/>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.1847"?> <!-- Multipart/signed -->
</references>
<section title="Acknowledgements"> numbered="false" toc="default">
<name>Acknowledgements</name>
<t>This document is a product of the JMAP Working Group.
Special thank you to Bron Gondwana, Neil Jenkins, Murray Kucherawy,
Kirsty Paine, Benjamin Kaduk, Roman Danyliw, Peter Yee, Robert Wilton,
Erik Kline and Menachem Dodge <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 comments, and corrections to this document.
</t>
</section>
</back>
</rfc>