rfc9219xml2.original.xml		rfc9219.xml
	<?xml version="1.0" encoding="US-ASCII"?>		<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd">		<!DOCTYPE rfc [
	<?rfc toc="yes"?>		<!ENTITY nbsp "&#160;">
	<?rfc rfcedstyle="yes"?>		<!ENTITY zwsp "&#8203;">
	<?rfc subcompact="no"?>		<!ENTITY nbhy "&#8209;">
	<?rfc symrefs="yes"?>		<!ENTITY wj "&#8288;">
	<?rfc comments="yes" ?>		]>
	<?rfc inline="yes" ?>
	<rfc ipr="trust200902" category="std" docName='draft-ietf-jmap-smime-12'>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" submissionType
			="IETF" category="std" consensus="true" docName="draft-ietf-jmap-smime-12" numbe
			r="9219" obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs="true"
			sortRefs="true" version="3">
			<!-- xml2rfc v2v3 conversion 3.12.0 -->
	<front>		<front>
	<title abbrev="JMAP extension for S/MIME">		<title abbrev="JMAP Extension for S/MIME">
	S/MIME signature verification extension to JMAP		S/MIME Signature Verification Extension to the JSON Meta Application Protoco
			l
			(JMAP)
	</title>		</title>
			<seriesInfo name="RFC" value="9219"/>
	<author initials="A." surname="Melnikov" fullname="Alexey Melnikov">		<author initials="A." surname="Melnikov" fullname="Alexey Melnikov">
	<organization>Isode Ltd</organization>		<organization>Isode Ltd</organization>
	<address>		<address>
	<postal>		<postal>
	<street>14 Castle Mews</street>		<street>14 Castle Mews</street>
	<city>Hampton</city>		<city>Hampton, Middlesex</city>
	<region>Middlesex</region>		<code>TW12 2NP</code>
	<code>TW12 2NP</code>		<country>United Kingdom</country>
	<country>UK</country>		</postal>
	</postal>		<email>Alexey.Melnikov@isode.com</email>
	<email>Alexey.Melnikov@isode.com</email>
	</address>		</address>
	</author>		</author>
			<date year="2022" month="March" />
	<date year="2022" />
	<keyword>JMAP</keyword>		<keyword>JMAP</keyword>
	<keyword>S/MIME</keyword>		<keyword>S/MIME</keyword>
	<abstract>		<abstract>
			<t>
	<t>		This document specifies an extension to "The JSON Meta Application Protoc
	This document specifies an extension to JMAP for Mail (RFC 8621) for returni		ol
	ng S/MIME signature verification status.		(JMAP) for Mail" (RFC 8621) for returning the S/MIME signature verificati
	</t>		on status.
			</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
			<section numbered="true" toc="default">
	<section title="Introduction">		<name>Introduction</name>
			<t>
	<t>		<xref target="RFC8621" format="default">JMAP for Mail</xref> is a JSON-b
	<xref target="RFC8621">JMAP for Mail</xref> is a JSON-based application		ased application protocol for synchronizing email data
	protocol for synchronising email data
	between a client and a server.		between a client and a server.
			</t>
	<!--		<t>
	JMAP [RFC8620] is a generic protocol for synchronising		This document describes an extension to JMAP for returning the S/MIME
	data, such as mail, calendars or contacts, between a client and a		signature verification status <xref target="RFC8551"
	server. It is optimised for mobile and web environments, and aims to		format="default"/>, without requiring a JMAP client to download the
	provide a consistent interface to different data types.		signature body part and all signed body parts (when the
	[RFC8621] builds on top of JMAP and defines how to perform		multipart/signed media type <xref target="RFC1847" format="default"/>
	email synchronization.		is used) or to download and decode the Cryptographic Message Syntax (CMS
	</t>		)
			(when the application/pkcs7-mime media type (<xref target="RFC8551"
	<t>		section="3.2" sectionFormat="of" format="default"/>) is used). The
	This document describes an extension to JMAP for returning S/MIME <xref		use of the extension implies the client trusts the JMAP server's
	target="RFC8551"/> signature verification status,		S/MIME signature verification code and configuration. This extension
	without requiring a JMAP client to download the signature body part and		is suitable for cases where reduction in network bandwidth and
	all signed body parts		client-side code complexity outweigh security concerns about trusting
	(when the multipart/signed media type <xref target="RFC1847"/> is used)		the JMAP server to perform S/MIME signature verifications. One
	or to download and decode CMS (when the application/pkcs7-mime media typ		possible use case is when the same organization controls both the JMAP
	e (Section 3.2 of <xref target="RFC8551"/>)		server and the JMAP client.
	is used).		</t>
	The use of the extension implies the client trusts the JMAP server's S/M
	IME signature verification code and configuration.
	This extension is suitable for cases where reduction in network bandwidt
	h 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>
			<section numbered="true" toc="default">
	<section title="Conventions Used in This Document">		<name>Conventions Used in This Document</name>
			<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",		"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMEND
	and "OPTIONAL" in this document are to be interpreted as described in		ED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>",
	BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only		and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
	when, they		described in
			BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174"
			format="default"/> when, and only when, they
	appear in all capitals, as shown here.		appear in all capitals, as shown here.
	</t>		</t>
	<t>		<t>
	Type signatures, examples, and property descriptions in this document		Type signatures, examples, and property descriptions in this document
	follow the conventions established in Section 1.1 of <xref target="RFC8620 "/>.		follow the conventions established in <xref target="RFC8620" section="1.1" sectionFormat="of" format="default"/>.
	Data types defined in the core specification are also used in this documen t.		Data types defined in the core specification are also used in this documen t.
	</t>		</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Addition to the capabilities object">		<name>Addition to the Capabilities Object</name>
	<t>		<t>
	The capabilities object is returned as part of the standard JMAP		The <strong>capabilities</strong> object is returned as part of the stan
	Session object; see Section 2 of <xref target="RFC8620"/>. Servers supp		dard JMAP
	orting _this_		Session object; see <xref target="RFC8620" section="2" sectionFormat="of
	specification MUST add a property called		" format="default"/>.
			Servers supporting this
			specification <bcp14>MUST</bcp14> add a property called
	"urn:ietf:params:jmap:smimeverify" to the capabilities object.		"urn:ietf:params:jmap:smimeverify" to the capabilities object.
	</t>		</t>
	<t>		<t>
	The value of this property is an empty object in both the JMAP		The value of this property is an empty object in both the JMAP
	session _capabilities_ property and an account's		Session <em>capabilities</em> property and an account's
	_accountCapabilities_ property.		<em>accountCapabilities</em> property.
	</t>		</t>
	</section>		</section>
			<section anchor="smime" numbered="true" toc="default">
			<name>Extension for S/MIME Signature Verification</name>
			<section anchor="email-get-ext" numbered="true" toc="default">
			<name>Extension to Email/get</name>
			<t>
	<section title="Extension for S/MIME signature verification" anchor="smime">		<xref target="RFC8621" format="default"/> defines the Email/get method f
			or retrieving message-specific information.
	<section title="Extension to Email/get" anchor="email-get-ext">		This document defines the following pseudo values in the <em>properties<
	<t>		/em> argument:</t>
	<xref target="RFC8621"/> defines the Email/get method for retrieving messa		<dl newline="true" spacing="normal">
	ge specific information.		<dt><strong>smimeStatus</strong>:</dt>
	This document defines the following pseudo values in the _properties_ ar		<dd>If "smimeStatus" is included in the list of requested
	gument:<vspace/>		properties, it <bcp14>MUST</bcp14> be interpreted by the server as a r
	<list style="bullets">		equest to
			return the "smimeStatus" response property.</dd>
	<t>*smimeStatus*: If "smimeStatus" is included in the list of requested		<dt><strong>smimeStatusAtDelivery</strong>:</dt>
	properties, it MUST be interpreted by the server as a request to		<dd>If "smimeStatusAtDelivery" is included in the list of requested
	return the "smimeStatus" response property.</t>		properties, it <bcp14>MUST</bcp14> be interpreted by the server as a req
			uest to
	<t>*smimeStatusAtDelivery*: If "smimeStatusAtDelivery" is included in th		return the "smimeStatusAtDelivery" response property. (It is effectively
	e list of requested		the same as
	properties, it MUST be interpreted by the server as a request to		the "smimeStatus"
	return the "smimeStatusAtDelivery" response property. (It is effectively		value calculated at the date/time of delivery, as specified by "received
	the same as the "smimeStatus"		At".)</dd>
	value calculated at the date/time of delivery, as specified by "received		<dt><strong>smimeErrors</strong>:</dt>
	At".)</t>		<dd>If "smimeErrors" is included in the list of requested
			properties, it <bcp14>MUST</bcp14> be interpreted by the server as a req
	<t>*smimeErrors*: If "smimeErrors" is included in the list of requested		uest to
	properties, it MUST be interpreted by the server as a request to		return the "smimeErrors" response property.</dd>
	return the "smimeErrors" response property.</t>		<dt><strong>smimeVerifiedAt</strong>:</dt>
			<dd>If "smimeVerifiedAt" is included in the list of requested
	<!--///Rename "smimeVerifiedAt" to "smimeValidatedAt" everywhere?-->		properties, it <bcp14>MUST</bcp14> be interpreted by the server as a req
	<t>*smimeVerifiedAt*: If "smimeVerifiedAt" is included in the list of re		uest to
	quested		return the "smimeVerifiedAt" response property.</dd>
	properties, it MUST be interpreted by the server as a request to		</dl>
	return the "smimeVerifiedAt" response property.</t>		<t>The "smimeStatus" response property is defined as follows:</t>
			<dl newline="true" spacing="normal">
	</list>		<dt><strong>smimeStatus</strong>:</dt>
	</t>		<dd><t>"String|null" (server-set). null signifies that the message does
			n't
	<t>The "smimeStatus" response property is defined as follows:</t>
	<t>
	smimeStatus: "String|null" (server-set). null signifies that the message
	doesn't
	contain any signature. Otherwise, this property contains the S/MIME sign ature		contain any signature. Otherwise, this property contains the S/MIME sign ature
	and certificate verification status calculated according to		and certificate verification status calculated according to
	<xref target="RFC8551"/> and <xref target="RFC8550"/><!--and RFC 5280 th at the latter depends on -->.		<xref target="RFC8551" format="default"/>, <xref target="RFC8550" format ="default"/>, and <xref target="RFC5280" format="default"/>.
	Possible string values of the property are		Possible string values of the property are
	listed below. Servers MAY return other values not defined below,		listed below. Servers <bcp14>MAY</bcp14> return other values not define d below,
	as defined in extensions to this document.		as defined in extensions to this document.
	<!--///Alexey (based on feedback from Murray): maybe just use "unknown"		Clients <bcp14>MUST</bcp14> treat unrecognized values as "unknown" or "s
	and clarify that some will treat		igned/failed".
	"unknown" as "signed/failed" for security reasons?-->		Note that the value of this property might change over time.</t>
	Clients MUST treat unrecognized values as "unknown" or "signed/failed".		<dl newline="true" spacing="normal">
	Note that the value of this property might change over time.		<dt>unknown:</dt>
			<dd>
	<list style="hanging">		An S/MIME message, but it was neither signed nor encrypted.
	<t hangText="unknown:">		This can also be returned for a multipart/signed message that
	S/MIME message, but it was neither signed nor encrypted.		contains an unrecognized signing protocol (for example, OpenPGP).
	This can also be returned for a multipart/signed message which		</dd>
	contains an unrecognized signing protocol (for example OpenPGP).		<dt>signed:</dt>
	</t>		<dd>
			An S/MIME signed message, but the signature was not yet
	<t hangText="signed:">
	S/MIME signed message, but the signature was not yet
	verified. Some servers might not attempt to verify a signature		verified. Some servers might not attempt to verify a signature
	until a particular message is requested by the client.		until a particular message is requested by the client.
	(This is a useful optimization for a JMAP server to avoid doing work		(This is a useful optimization for a JMAP server to avoid doing work
	until exact information is needed.		until exact
	A JMAP client that only needs to display an icon that signifies pres		information is needed.
	ence of an S/MIME signature can still use this value.)		A JMAP client that only needs to display an icon that signifies pres
	JMAP servers compliant with this document SHOULD attempt signature v		ence of an
	erification		S/MIME signature can still use this value.)
			JMAP servers compliant with this document <bcp14>SHOULD</bcp14> atte
			mpt signature
			verification
	and return "signed/verified" or "signed/failed" instead of this sign ature		and return "signed/verified" or "signed/failed" instead of this sign ature
	status.		status.
	</t>		</dd>
			<dt>signed/verified:</dt>
	<t hangText="signed/verified:">		<dd>
	S/MIME signed message and the sender's signature		An S/MIME signed message, and the sender's signature
	was successfully verified according to		was successfully verified according to
	<xref target="RFC8551"/> and <xref target="RFC8550"/>.		<xref target="RFC8551" format="default"/> and <xref target="RFC8550"
	Additionally the signer email address extracted from the S/MIME		format="default"/>.
			Additionally, the signer email address extracted from the S/MIME
	certificate matches the From header field value, and		certificate matches the From header field value, and
	the signer certificate SHOULD be checked for revocation.		the signer certificate <bcp14>SHOULD</bcp14> be checked for revocati
	</t>		on.
			</dd>
	<t hangText="signed/failed:">		<dt>signed/failed:</dt>
			<dd>
	S/MIME signed message, but the signature failed to		S/MIME signed message, but the signature failed to
	verify according to <xref target="RFC8551"/> and <xref target="RFC85		verify according to <xref target="RFC8551" format="default"/> and <x
	50"/>.		ref
	This might be a policy related decision (e.g. the message signer ema		target="RFC8550" format="default"/>.
	il address		This might be because of a policy-related decision (e.g., the messag
	doesn't match the From header field value), message was modified,		e 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.		the signer's certificate has expired or was revoked, etc.
	</t>		</dd>
			<dt>encrypted+signed/verified:</dt>
	<t hangText="encrypted+signed/verified:">		<dd>
	This value is reserved for future use. It is typically handled in th e same way as "signed/verified".		This value is reserved for future use. It is typically handled in th e same way as "signed/verified".
	</t>		</dd>
			<dt>encrypted+signed/failed:</dt>
	<t hangText="encrypted+signed/failed:">		<dd>
	This value is reserved for future use. It is typically handled in th e same way as "signed/failed".		This value is reserved for future use. It is typically handled in th e same way as "signed/failed".
	</t>		</dd>
			</dl>
	</list>		</dd>
	</t>		</dl>
			<t>The "smimeStatusAtDelivery" response property
	<t>The "smimeStatusAtDelivery" response property
	has the same syntax as "smimeStatus" but is calculated in relationship to the "receivedAt"		has the same syntax as "smimeStatus" but is calculated in relationship to the "receivedAt"
	date/time.		date/time.
	Unlike "smimeStatus", the "smimeStatusAtDelivery" response property		Unlike "smimeStatus", the "smimeStatusAtDelivery" response property
	value doesn't change, unless Trust Anchors are added. (For example, additi on of a Trust Anchor		value doesn't change unless trust anchors are added. (For example, additio n of a trust anchor
	can change the value of a message "smimeStatusAtDelivery" property from "s igned/failed"		can change the value of a message "smimeStatusAtDelivery" property from "s igned/failed"
	to "signed/verified". Note that Trust Anchor removal doesn't affect this r		to "signed/verified". Note that trust anchor removal doesn't affect this r
	esponse property.)		esponse property.)
	The "smimeStatusAtDelivery" allows clients to compare the S/MIME		The "smimeStatusAtDelivery" response property value allows clients to comp
			are the S/MIME
	signature verification status at delivery with the current status as retur ned		signature verification status at delivery with the current status as retur ned
	by "smimeStatus", for example to help to answer questions like		by "smimeStatus", for example, to help to answer questions like
	"was the signature valid at the time of delivery?".		"was the signature valid at the time of delivery?".
	</t>		</t>
			<t>Note that the "smimeStatusAtDelivery" response property
	<t>Note that the "smimeStatusAtDelivery" response property
	value doesn't have to be calculated at delivery time. A JMAP server		value doesn't have to be calculated at delivery time. A JMAP server
	can defer its calculation until it is explicitly requested,		can defer its calculation until it is explicitly requested;
	but once calculated its value is remembered for later use.		however, once it is calculated, its value is remembered for later use.
	</t>		</t>
			<t>The "smimeErrors" response property is defined as follows:</t>
	<t>The "smimeErrors" response property is defined as follows:</t>		<dl newline="true" spacing="normal">
			<dt><strong>smimeErrors</strong>:</dt>
	<t>		<dd>"String[]|null" (server-set). null signifies that the message doesn
	smimeErrors: "String[]|null" (server-set). null signifies that the messa		't
	ge doesn't
	contain any signature or that there were no errors when verifying		contain any signature or that there were no errors when verifying
	the S/MIME signature. (I.e., this property is non null only		the S/MIME signature. (That is, this property is non-null only
	when the corresponding "smimeStatus" response property value		when the corresponding "smimeStatus" response property value
	is "signed/failed" or "encrypted+signed/failed". Note that future extens		is "signed/failed" or "encrypted+signed/failed".
	ions to this document		Note that future extensions to this document
	can specify other smimeStatus values that can be used with smimeErrors.)		can specify other "smimeStatus" values that can be used with "smimeError
	Each string in the array is a human readable description		s".)
			Each string in the array is a human-readable description
	(in the language specified in the Content-Language header field, if any)		(in the language specified in the Content-Language header field, if any)
	of a problem with the signature, the signing certificate or the signing		of a problem with the signature, the signing certificate, or the signing
	certificate chain.		certificate
	(See Section 3.8 of <xref target="RFC8620"/> in regards to how this is a		chain.
	ffected		(See <xref target="RFC8620" section="3.8" sectionFormat="of" format="def
			ault"/> in regards to how this
			is affected
	by the language selection.)		by the language selection.)
	In one example, the signing certificate might be expired		In one example, the signing certificate might be expired
	and the message From email address might not correspond to any of the em ail		and the message From email address might not correspond to any of the em ail
	addresses in the signing certificate.		addresses in the signing certificate.
	In another example the certificate might be expired and the JMAP server		In another example, the certificate might be expired and the JMAP server
	might be unable		might
	to retrieve a CRL for the certificate.		be unable
	In both of these cases there would be 2 elements in the array.		to retrieve a Certificate Revocation List (CRL) for the certificate.
	</t>		In both of these cases, there would be 2 elements in the array.
			</dd>
	<t>The "smimeVerifiedAt" response property is defined as follows:</t>		</dl>
			<t>The "smimeVerifiedAt" response property is defined as follows:</t>
	<t>		<dl newline="true" spacing="normal">
	smimeVerifiedAt: "UTCDate|null" (server-set). null signifies that the me		<dt><strong>smimeVerifiedAt</strong>:</dt>
	ssage doesn't		<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		contain any S/MIME signature or that there is a signature, but there was no attempt
	to verify it.		to verify it.
	(Retrieval of the smimeStatus value can be used to distinguish these 2 c		(Retrieval of the "smimeStatus" value can be used to distinguish these 2
	ases).		cases).
	In all other cases it is set to the date and time of when the S/MIME sig		In all other cases, it is set to the date and time of when the S/MIME si
	nature		gnature
	was most recently verified.		was most recently verified.
	Note that a request to fetch "smimeStatus", "smimeStatusAtDelivery" and/		Note that a request to fetch "smimeStatus", "smimeStatusAtDelivery", and
	or "smimeErrors" would force this response		/or "smimeErrors" would force this response
	property to be set to a non null value, if an S/MIME signature exists.		property to be set to a non-null value if an S/MIME signature exists.
	</t>		</dd>
			</dl>
	<t>"smimeStatus" and "smimeErrors" values are calculated at the time the c		<t>The "smimeStatus" and "smimeErrors" values are calculated at the time
	orresponding JMAP		the
	request was processed (but see below about the effect of result caching),		corresponding JMAP
	not at the time when the message was generated (according to its		request is processed (but see below about the effect of result caching),
	Date header field value). In all cases "smimeVerifiedAt" is set to the tim		not at the time when the message is generated (according to its
	e when		Date header field value). In all cases, "smimeVerifiedAt" is set to the ti
			me when
	"smimeStatus" and "smimeErrors" were last updated.		"smimeStatus" and "smimeErrors" were last updated.
	As recalculating these values is expensive for the server,		As recalculating these values is expensive for the server,
	<!--This seems to be a reasonable balance between doing online CRL / OCSP		they <bcp14>MAY</bcp14> be cached for up to 24 hours from the moment when
	checks right away		they were calculated.
	and typical expiration period for certificates.-->		</t>
	they MAY be cached for up to 24 hours from the moment when they were calcu		<t keepWithNext="true">
	lated.		Example 1: Retrieval of minimal information about a message, including i
	</t>		ts From, Subject, and Date header fields,
			as well as the S/MIME signature verification status at delivery and date
	<figure>		/time when the message was received.
	<preamble>		</t>
	Example 1: Retrieval of minimal information about a message, including i
	ts From, Subject and Date header fields,
	as well as S/MIME signature verification status at delivery and date/tim
	e when the message was received.
	</preamble>
	<artwork><![CDATA[
	["Email/get", {
	"ids": [ "fe123u457" ],
	"properties": [ "mailboxIds", "from", "subject", "date",
	"smimeStatusAtDelivery", "receivedAt" ]
	}, "#1"]
	This might result in the following response:
	[["Email/get", {		<sourcecode name="" type=""><![CDATA[
	"accountId": "abc",		["Email/get", {
	"state": "51234123231",		"ids": [ "fe123u457" ],
	"list": [		"properties": [ "mailboxIds", "from", "subject", "date",
	{		"smimeStatusAtDelivery", "receivedAt" ]
	"id": "fe123u457",		}, "#1"]
	"mailboxIds": { "f123": true },		]]></sourcecode>
	"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>		<t>This might result in the following response:</t>
	<preamble>		<sourcecode name="" type=""><![CDATA[
	Example 2: Retrieval of minimal information about a message, including i		[["Email/get", {
	ts From, Subject and Date header fields,		"accountId": "abc",
	as well as the latest S/MIME signature verification status, S/MIME verif		"state": "51234123231",
	ication errors (if any) and		"list": [
	when was the S/MIME signature status last verified.		{
			"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">
			Example 2: Retrieval of minimal information about a message, including i
			ts From, Subject, and Date header fields,
			as well as the latest S/MIME signature verification status, S/MIME verif
			ication 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 verifi cation.		The response contains 2 S/MIME errors related to S/MIME signature verifi cation.
	</preamble>		</t>
	<artwork><![CDATA[		<sourcecode name="" type=""><![CDATA[
	["Email/get", {		["Email/get", {
	"ids": [ "ag123u123" ],		"ids": [ "ag123u123" ],
	"properties": [ "mailboxIds", "from", "subject", "date",		"properties": [ "mailboxIds", "from", "subject", "date",
	"smimeStatus", "smimeErrors", "smimeVerifiedAt" ]		"smimeStatus", "smimeErrors", "smimeVerifiedAt" ]
	}, "#1"]		}, "#1"]
			]]></sourcecode>
	This might result in the following response:		<t>This might result in the following response:</t>
			<sourcecode name="" type=""><![CDATA[
	[["Email/get", {		[["Email/get", {
	"accountId": "abc",		"accountId": "abc",
	"state": "47234123231",		"state": "47234123231",
	"list": [		"list": [
	{		{
	"id": "ag123u123",		"id": "ag123u123",
	"mailboxIds": { "f123": true },		"mailboxIds": { "f123": true },
	"from": [{"name": "Jane Doe",		"from": [{"name": "Jane Doe",
	"email": "jdoe@example.com"}],		"email": "jdoe@example.com"}],
	"subject": "Company takeover",		"subject": "Company takeover",
	"date": "2020-01-31T23:00:00Z",		"date": "2020-01-31T23:00:00Z",
	"smimeStatus": "signed/failed",		"smimeStatus": "signed/failed",
	"smimeErrors": [		"smimeErrors": [
	"From email address doesn't match the certificate",		"From email address doesn't match the certificate",
	"Can't retrieve CRL from the CRL URL"],		"Can't retrieve CRL from the CRL URL"],
	"smimeVerifiedAt": "2020-03-01T12:11:19Z"		"smimeVerifiedAt": "2020-03-01T12:11:19Z"
	}		}
	]		]
	}, "#1"]]		}, "#1"]]
	]]></artwork>		]]></sourcecode>
	<postamble>		<section numbered="true" toc="default">
	</postamble>		<name>"smimeStatus" Response Property Extensibility</name>
	</figure>
	<section title='"smimeStatus" response property extensibility'>
	<t>		<t>
	Future extensions to this document can specify extra allowed values fo		Future extensions to this document can specify extra allowed values fo
	r the smimeStatus response property.		r the "smimeStatus" response property.
	All values (defined in this document or in extensions to this document		All values (defined in this document or in extensions to this document
	) MUST be in ASCII.		) <bcp14>MUST</bcp14> be in ASCII.
	(Note that this response property contains tokens, thus it is not subj		(Note that this response property contains tokens; thus, it is not sub
	ect to		ject to
	Internationalization or Localization).		internationalization or localization).
	</t>		</t>
	<t>		<t>
	New smimeStatus response property values defined in extensions may aff		New "smimeStatus" response property values defined in extensions may a
	ect behaviour of		ffect the behavior of
	properties such as smimeErrors response property of Email/get (see <xr		properties, such as the "smimeErrors" response property of Email/get (
	ef target="email-get-ext"/>) or		see <xref target="email-get-ext" format="default"/>) or the
	hasVerifiedSmime property of Email/query (see <xref target="email-quer		"hasVerifiedSmime" property of Email/query (see <xref target="email-qu
	y-ext"/>). In particular		ery-ext" format="default"/>). In particular,
	the new values can be treated similar to values defined in this docume		the new values can be treated similarly to values defined in this docu
	nt.		ment.
	</t>		</t>
	<t>		<t>
	<!--///Should this be reworded to allow for reserved "encrypted+signed		For example, a putative JMAP extension for automatically decrypting S/
	/failed" and "encrypted+signed/verified"?-->		MIME messages can specify
	For example a putative JMAP extension for automatically decrypting S/M
	IME messages can specify
	two additional values, one specifying that a message is both encrypted and signed with a valid S/MIME signature		two additional values, one specifying that a message is both encrypted and signed with a valid S/MIME signature
	and another one specifying that a message is both encrypted and signed		(e.g. "encrypted+signed/verified")
	with an invalid S/MIME signature.		and another one specifying that a message is both encrypted and signed
	The former value can be treated as "signed/verified" (and would thus a		with an invalid S/MIME signature
	ffect hasVerifiedSmime)		(e.g. "encrypted+signed/failed").
	and the latter can be treated as "signed/failed" (and thus can be used		The former value can be treated as "signed/verified" (and would thus a
	with smimeErrors).		ffect "hasVerifiedSmime")
			and the latter can be treated as "signed/failed" (and thus can be used
			with "smimeErrors").
	</t>		</t>
	</section>		</section>
	</section>		</section>
			<section anchor="email-query-ext" numbered="true" toc="default">
			<name>Extension to Email/query</name>
			<t>
			<xref target="RFC8621" format="default"/> defines the Email/query method
			for searching for messages with specific properties.
			This document defines the following properties of the <strong>FilterCond
			ition</strong> object:
	<section title="Extension to Email/query" anchor="email-query-ext">		</t>
	<t>		<dl newline="true" spacing="normal">
	<xref target="RFC8621"/> defines the Email/query method for searching fo		<dt><strong>hasSmime</strong>:</dt>
	r messages with specific properties.		<dd>"Boolean". If "hasSmime" has the value true, only messages with "sm
	This document defines the following properties of the *FilterCondition*		imeStatus"
	object:		other than null match the condition.
			If "hasSmime" has the value false, only messages with "smimeStatus" eq
	<list style="bullets">		ual to null
			match the condition.</dd>
	<t>*hasSmime*: "Boolean". If "hasSmime" has the value true, only messa		<dt><strong>hasVerifiedSmime</strong>:</dt>
	ges with "smimeStatus" other than null match the condition.		<dd><t>"Boolean". If "hasVerifiedSmime" has the value true, only messag
	If "hasSmime" has the value false, only messages with "smimeStatus" eq		es with
	ual to null match the condition.</t>		"smimeStatus" equal
			to "signed/verified" or "encrypted+signed/verified" (*) match the cond
	<t>*hasVerifiedSmime*: "Boolean". If "hasVerifiedSmime" has the value		ition.
	true, only messages with "smimeStatus" equal		If "hasVerifiedSmime" has the value false, only messages with "smimeSt
	to "signed/verified" or "encrypted+signed/verified" (*), match the con		atus" not
	dition.		equal
	If "hasVerifiedSmime" has the value false, only messages with "smimeSt		to "signed/verified" and not equal to "encrypted+signed/verified" (*)
	atus" not equal		(including
	to "signed/verified" and not equal to "encrypted+signed/verified" (*)		the value null) match the condition.
	(including the value null) match the condition.		Note that use of this attribute is potentially expensive for a JMAP se
	Note that use of this attribute is potentially expensive for a JMAP se		rver, as it
	rver, as it forces		forces
	calculation of smimeStatus property value for each message. However ca		calculation of the "smimeStatus" property value for each message. Howe
	ching of smimeStatus		ver, caching of the
	values should ameliorate this cost somewhat.<vspace/>		"smimeStatus"
			values should ameliorate this cost somewhat.</t>
	(*) as well as "smimeStatus" values added by future extensions to this		<t>
	document		(*) as well as the "smimeStatus" values added by future extensions to
	that are explicitly specified as having similar effect to "signed/veri		this document
	fied" as far as		that are explicitly specified as having similar effect to "signed/veri
	"hasVerifiedSmime" calculation is concerned.		fied" as far
	</t>		as
			"hasVerifiedSmime" calculation is concerned.</t></dd>
	<t>*hasVerifiedSmimeAtDelivery*: "Boolean". The "hasVerifiedSmimeAtDel		<dt><strong>hasVerifiedSmimeAtDelivery</strong>:</dt>
	ivery" property is handled similar to "hasVerifiedSmime" property,		<dd>"Boolean". The "hasVerifiedSmimeAtDelivery" property is handled sim
			ilarly to
			the "hasVerifiedSmime" property,
	but the value of "smimeStatusAtDelivery" is used instead of "smimeStat us" to assess		but the value of "smimeStatusAtDelivery" is used instead of "smimeStat us" to assess
	whether a particular message matches the condition.		whether a particular message matches the condition.
	</t>		</dd>
			</dl>
	</list>
	</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Interaction with Email/changes">		<name>Interaction with Email/changes</name>
			<t>Changes to the "smimeVerifiedAt" response property value <bcp14>MUST
	<t>Changes to "smimeVerifiedAt" response property value MUST NOT		NOT</bcp14>
	cause the message to be included in the "updated" argument of Email/chan		cause the message to be included in the "updated" argument of the Email/
	ges response.		changes response.
	However changes to "smimeStatus", "smimeStatusAtDelivery" and/or "smimeE		However, changes to the "smimeStatus", "smimeStatusAtDelivery", and/or "
	rrors"		smimeErrors"
	response properties MUST result in message inclusion in the "updated" ar		response properties <bcp14>MUST</bcp14> result in message inclusion in t
	gument of Email/changes response.		he "updated" argument of the
			Email/changes response.
	</t>		</t>
	</section>		</section>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="IANA Considerations">		<name>IANA Considerations</name>
			<section numbered="true" toc="default">
	<section title='JMAP capability registration for "smimeverify"'>		<name>JMAP Capability Registration for "smimeverify"</name>
	<t>
	IANA is requested to register the "smimeverify" JMAP Capability as fol
	lows:
	</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>		<t>
	Security and privacy considerations: this document, <xref target="secc ons"/>		IANA has registered the "smimeverify" JMAP capability as follows:
	</t>		</t>
			<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:</dt>
			<dd>RFC 9219, <xref target="seccons" format="default"/></dd>
			</dl>
	</section>		</section>
	</section>		</section>
			<section anchor="seccons" numbered="true" toc="default">
	<section title="Security Considerations" anchor="seccons">		<name>Security Considerations</name>
	<t>		<t>
	Use of the server-side S/MIME signature verification JMAP extension requir es		Use of the server-side S/MIME signature verification JMAP extension requir es
	the client to trust the server signature verification code, server configu		the client to trust the server signature verification code, the server con
	ration and its operational practices		figuration, and
			the server's operational practices
	to perform S/MIME signature verification, as well as to trust that the cha nnel between		to perform S/MIME signature verification, as well as to trust that the cha nnel between
	the client and the server is integrity protected.		the client and the server is integrity protected.
	(For example, if the server is not configured		(For example, if the server is not configured
	with some Trust Anchors, some messages will have "signed/failed" status in		with some trust anchors, some messages will have the "signed/failed" statu
	stead of		s
	"signed/verified".)		instead of "signed/verified".)
	A malicious or compromised server could		A malicious or compromised server could
	return false verification status to a client. A successful verification c ould		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 signe d		be conveyed to a client for a forged or altered message. A properly signe d
	message could be signaled as having a failed signature verification or no		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		signature at all. In the case of the latter attack, no new attack surface is
	presented with this extension above what malicious or compromised server c ould		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		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		message. In the case of the former attack, client software capable of
	performing S/MIME signature verification could detect this attack. Local		performing S/MIME signature verification could detect this attack. Local
	configuration of the client should determine if this client-side verificat ion		configuration of the client should determine if this client-side verificat ion
	should occur. For clients without local verification capabilities, such a n		should occur. For clients without local verification capabilities, such a n
	attack would be difficult to detect.		attack would be difficult to detect.
	</t>		</t>
	<t>		<t>
	Integrity protection of the channel between the client and the server is p rovided by use of TLS,		Integrity protection of the channel between the client and the server is p rovided by use of TLS,
	as required by JMAP specification (see Section 8.1 of <xref target="RFC862 0"/>).		as required by the JMAP specification (see <xref target="RFC8620" section= "8.1" sectionFormat="of" format="default"/>).
	</t>		</t>
			<t>Constant recalculation of the S/MIME signature status can result in a d
	<t>Constant recalculation of S/MIME signature status can result in a Denia		enial-of-service condition.
	l-of-Service condition.		For that reason, it is <bcp14>RECOMMENDED</bcp14> that servers cache resul
	For that reason, it is RECOMMENDED that servers cache results of signature		ts of signature verification for up to 24 hours.</t>
	verification for up to 24 hours.</t>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
	<references title="Normative References">		<references>
	<?rfc include="reference.RFC.2119"?> <!-- Keywords. BCP 14, part 1. -->		<name>References</name>
	<?rfc include="reference.RFC.8174"?> <!-- Keywords. BCP 14, part 2. -->		<references>
	<?rfc include="reference.RFC.8550"?> <!-- S/MIME Certificate Handling -->		<name>Normative References</name>
	<?rfc include="reference.RFC.8551"?> <!-- S/MIME Message Format -->		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2
	<?rfc include="reference.RFC.8620"?> <!-- JMAP Core -->		119.xml"/>
	<?rfc include="reference.RFC.8621"?> <!-- JMAP Mail -->		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8
			174.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5
			280.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8
			550.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8
			551.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8
			620.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8
			621.xml"/>
	</references>		</references>
			<references>
	<references title="Informative References">		<name>Informative References</name>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1
	<?rfc include="reference.RFC.1847"?> <!-- Multipart/signed -->		847.xml"/>
	</references>		</references>
			</references>
	<section title="Acknowledgements">		<section numbered="false" toc="default">
			<name>Acknowledgements</name>
	<t>This document is a product of the JMAP Working Group.		<t>This document is a product of the JMAP Working Group.
	Special thank you to Bron Gondwana, Neil Jenkins, Murray Kucherawy,		Special thank you to <contact fullname="Bron Gondwana"/>, <contact fullnam
	Kirsty Paine, Benjamin Kaduk, Roman Danyliw, Peter Yee, Robert Wilton,		e="Neil
	Erik Kline and Menachem Dodge for suggestions, comments and corrections to		Jenkins"/>, <contact fullname="Murray Kucherawy"/>, <contact fullname="Kir
	this document.		sty 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>		</t>
	</section>		</section>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 81 change blocks.
	464 lines changed or deleted		452 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/