<remark><p>Removed public key IDs from Offline options; harmonised session termination with the protocol added to XEP-0155; renamed logging field to otr</p></remark>
<p>The convenience of sending stanzas to other entities that are offline ("offline messages") is an important and popular feature of most XMPP implementations (see &xep0160;). Without offline messages delivery would have to wait until both entities managed to be online at the same time. So many urgent messages could not be delivered in time. For example, the sender might want to send an urgent message before jumping on a flight.</p>
<p>End-to-end encryption is another desirable feature for any communication technology. Unfortunately it is not possible to make offline encryption quite so secure as online encryption (see <linkurl='#sec'>Security Considerations</link>). However, offline encryption has a long history and is certainly preferable to having no encryption at all. <note>This protocol does not stop paranoid users avoiding sending offline messages.</note> Unfortunately, for reasons described in &xep0188;, the existing proposals (including &xep0027; and &rfc3923;) have not been widely implemented and deployed. This document describes a different approach to offline end-to-end encryption for use by entities that communicate using XMPP. It builds on the existing online &xep0116; protocol. As a result it offers important advantages over the existing "Object Encryption" proposals:</p>
<li>Perfect Forward Secrecy <note>Long-lived keys are typically used for a few years, whereas Offline ESession decryption keys typically exist for just a few hours. So the Perfect Forward Secrecy feature significantly enhances the security of Offline ESessions.</note></li>
<li>Other security features described in <cite>Cryptographic Design of Encrypted Sessions</cite></li>
<li>Most of the code can be borrowed from implementations of <cite>Encrypted Sessions</cite></li>
</ul>
<p>The requirements and the consequent cryptographic design that underpin this protocol are described in <cite>Cryptographic Design of Encrypted Sessions</cite>. The basic concept is that of an encrypted session which acts as a secure tunnel between the online endpoint and the offline endpoint. The offline endpoint completes its part of the tunnel "negotiation" by publishing its preferences before it goes offline. Once the tunnel is established by the online endpoint, the content of each one-to-one XML stanza sent by the online endpoint is encrypted and then transmitted within a "wrapper" stanza.</p>
<li>"Bob" is the name of the online participant in the offline ESession. Within the scope of this document, his fully-qualified JID is: <bob@example.com/laptop>.</li>
<li>"Alice" is the name of the offline participant in the offline ESession started by Bob. Within the scope of this document, we stipulate that her fully-qualified JID is: <alice@example.org/pda>.</li>
<p>While Bob and Alice are introduced as "end users", they are simply meant to be examples of Jabber entities. Any directly addressable Jabber entity may participate in an offline ESession.</p>
<p>The approach to establishing a secure session with an entity that is offline is in essence a special case of 3-message negotiation employed for online ESessions (see <cite>Encrypted Sessions</cite>).</p>
<p>Alice MAY publish a set of offline ESession options just before she goes offline. If Bob subscribes to Alice's presence and wishes to establish an online ESession with her, but he finds that she is offline, then if she published her offline ESession options before going offline, he may use the protocol described below to perform the initial Diffie-Hellman key exchange, establish an offline ESession and send encrypted stanzas to her while she is offline. Note: Bob MUST NOT initiate a new ESession with Alice if he already has an ESession established with her.</p>
<p>Note: Alice MAY also publish <em>another</em> similar set of relatively long-lived <note>The more often Alice changes her published ESession options, the shorter the Perfect Forward Secrecy window of vulnerability. However, whenever she changes them she divulges her presence to all the entities that are monitoring them.</note> offline ESession options that any entity MAY use for the same purpose.</p>
<p>In order to publish either set of her offline ESession options Alice MUST create an options data form in exactly the same way as she would create an online ESession request data form (see the ESession Request section in <cite>Encrypted Sessions</cite>) except she MUST omit The 'accept' and 'pk_hash' fields. Note: The list of stanza types she is willing to decrypt MUST NOT include the value 'iq'.</p>
<p>Alice MUST append to the content of the form an 'expires' field containing the UTC time (see &xep0082;) that she decides her offline ESession options will expire (see <linkurl='#sec-expire'>Options Expiry Time</link> Security Considerations).</p>
<p>Alice MUST store her value of &NsubA; (her ESession ID), all her values of x (one for each MODP group) and the time she decides her offline ESession options will expire in a secure way, so that she can retrieve them when she comes back online (idealy even if that is using a different client and/or a different machine).</p>
<p>If Alice would not be able to decrypt stanzas if she came back online using a different client and/or a different machine then she SHOULD also encapsulate the resource of her client in a 'match_resource' field and append it to her options data form. In this case, the list of stanza types she is willing to decrypt MUST include only 'message'.</p>
<p>Alice MUST also append to the content of the form a list of signatures (see <linkurl='#sign'>Signature Generation</link>) of the <em>content</em> of the data form (excluding the 'signs' field). The list SHOULD include one signature for each of the public signature-verification keys that other entities may use to authenticate her.</p>
<p>If the pubkey PEP node does not exist already then Alice MUST create it first. In this case, Alice SHOULD specify the "Presence" access model for the set of options for presence subscribers (or the "Open" model for the set for other entities), unless she wants greater control over access to her identity (see <linkurl='#sec-identity'>Identity Protection</link> Security Considerations). Alice SHOULD specify that the options will never be pushed to subscribers (even when she publishes new options) - especially if she specifies the "Whitelist" access model.</p>
<examplecaption='Alice Creates PEP Node for ESession Options for Presence Subscribers'><