<remark><p>Initial version, split off from XEP-0136 per XMPP Council consensus.</p></remark>
</revision>
</header>
<section1topic='Introduction'anchor='intro'>
<p>&xep0136; defines a technology for archiving messages at an XMPP server instead of locally on a client device. This specification defines methods for encrypting such messages.</p>
</section1>
<section1topic='Encryption of Manually-Archived Collections'anchor='manual'>
<p>Clients SHOULD encrypt manually-archived collections (although early implementations of this protocol MAY prefer to defer encryption and decryption to later releases). Servers MUST support the manual-archiving of encrypted collections.</p>
<p>Before uploading a sequence of messages to a collection, the client SHOULD select a symmetric data encryption algorithm, generate a suitable random encryption key, give the key a unique (for the user) name, encrypt the symmetric key with one of the user's public keys, and wrap the result inside one or more <EncryptedKey/> elements, as specified in &w3xmlenc;.</p>
<p>To ensure that all its user's clients will be able to decrypt the collection, the client SHOULD create one <EncryptedKey/> element for each of its user's public keys that are being published using &xep0189;. However, the client MUST NOT create an <EncryptedKey/> element for any public key until it has confirmed that it belongs to the user. Note: The fact that a public key is being published using <cite>XEP-0189</cite> is <em>not</em> sufficient proof of ownership, since the user's server may have been compromised at some stage. The method of confirmation is beyond the scope of this document.</p>
<p>The client SHOULD use the symmetric key to encrypt the joined sequence of <to/>, <from/> and <note/> elements, base64 encode the resulting sequence of bytes, and wrap it inside an <EncryptedData/> element, as described in <cite>XML Encryption</cite>.</p>
<p>Clients may add one or more <EncryptedData/> or <EncryptedKey/> elements to a collection using exactly the same method as for <to/>, <from/> and <note/> elements (see <linkurl='#manual-upload'>Uploading Messages to a Collection</link>). One collection may contain <EncryptedData/> elements encrypted with different symmetric keys.</p>
<p>When appending <EncryptedData/> elements to a collection, the client MAY reuse a symmetric Key that has already been uploaded to the collection. In this case the client SHOULD NOT resend <EncryptedKey/> elements.</p>
<p>Note: A collection that contains <EncryptedData/> or <EncryptedKey/> elements MUST NOT contain <to/> or <from/> or <note/> elements.</p>
<examplecaption='Storing encrypted messages and keys in a collection'><