One document matched: draft-miller-xmpp-e2e-04.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<rfc category="std" docName="draft-miller-xmpp-e2e-04" ipr="trust200902">
<front>
<title abbrev="XMPP E2E">End-to-End Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)</title>
<author initials="M." surname="Miller" fullname="Matthew Miller">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1899 Wynkoop Street, Suite 600</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>USA</country>
</postal>
<phone>+1-303-308-3204</phone>
<email>mamille2@cisco.com</email>
</address>
</author>
<date month="February" day="12" year="2013"/>
<area>RAI</area>
<workgroup>XMPP</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>Extensible Messaging and Presence Protocol</keyword>
<keyword>Jabber</keyword>
<abstract>
<t>This document defines a method of end-to-end object encryption for the Extensible Messaging and Presence Protocol (XMPP).</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>End-to-end encryption of traffic sent over the Extensible Messaging and Presence Protocol <xref target="RFC6120"/> is a desirable goal. Requirements and a threat analysis for XMPP encryption are provided in <xref target="E2E-REQ"/>. Many possible approaches to meet those (or similar) requirements have been proposed over the years, including methods based on PGP, S/MIME, SIGMA, and TLS.</t>
<t>Most proposals have not been able to support multiple end-points for a given recipient. As more devices support XMPP, it becomes more desirable to allow an entity to communicate with another in a more secure manner, regardless of the number of agents the entity is employing. This document specifies an approach for encrypting communications between two entities which each might have multiple end-points.</t>
</section>
<section title="Terminology" anchor="terms">
<t>This document inherits XMPP-related terminology from <xref target="RFC6120"/>, JSON Web Algorithms (JWA)-related terminology from <xref target="JOSE-JWA"/>, JSON Web Encryption (JWE)-related terminology from <xref target="JOSE-JWE"/>, and JSON Web Key (JWK)-related terminology from <xref target="JOSE-JWK"/>. Security-related terms are to be understood in the sense defined in <xref target="RFC4949"/>.</t>
<t>The capitalized 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="Determining Support" anchor="disco">
<t>If an agent supports end-to-end object encryption, it MUST advertize that fact in its responses to <xref target="XEP-0030"/> information ("disco#info") requests by returning a feature of "urn:ietf:params:xml:ns:xmpp-e2e:5".
<figure>
<artwork><![CDATA[
<iq xmlns='jabber:client'
id='disco1'
to='romeo@montegue.lit/garden'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
...
<feature xmlns='urn:ietf:params:xml:ns:xmpp-e2e:5'/>
...
</query>
</iq>
]]></artwork>
</figure>
</t>
<t>To help facilitate discovery, an agent SHOULD also include <xref target='XEP-0115'/> information in any directed or broadcast presence updates.</t>
</section>
<section title="Encrypting XMPP Stanzas" anchor="encrypt">
<t>The process that a sending agent follows for securing stanzas is the same regardless of the form of stanza (i.e., <iq/>, <message/>, or <presence/>).</t>
<section title="Prerequisites" anchor="encrypt-prereq">
<t>First, the sending agent prepares and retains the following:<vspace blankLines="1"/>
<list style="symbols">
<t>The JID of the sender (i.e. its own JID). This SHOULD be the bare JID (localpart@domainpart).<vspace blankLines="1"/></t>
<t>The JID of the recipient. This SHOULD be the bare JID (localpart@domainpart).<vspace blankLines="1"/></t>
<t>A Session Master Key (SMK). The SMK MUST have a length at least equal to that required by the key wrapping algorithm in use and MUST be generated randomly. See <xref target="RFC4086"/> for considerations on generating random values.<vspace blankLines="1"/></t>
<t>A SMK identifier (SID). The SID MUST be unique for a given (sender, recipient, SMK) tuple, and MUST NOT be derived from SMK itself.<vspace blankLines="1"/></t>
</list>
</t>
</section>
<section title="Process" anchor="encrypt-process">
<t>For a given plaintext stanza (S), the sending agent performs the following:<vspace blankLines="1"/>
<list style="numbers">
<t>Ensures the plaintext stanza is fully qualified, including the proper namespace declarations (e.g., contains the attribute 'xmlns' set to the value "jabber:client" for 'jabber:client' stanzas defined in <xref target="RFC6120"/>).<vspace blankLines="1"/></t>
<t>Notes the current UTC date and time (N) when this stanza is constructed, formatted as described under <xref target="timestamps"/>.<vspace blankLines="1"/></t>
<t>Constructs a forwarding envelope (M) using a <forwarded/> element qualified by the "urn:xmpp:forward:0" namespace (as defined in <xref target="XEP-0297"/>) as follows:<vspace blankLines="1"/>
<list style="symbols">
<t>The child element <delay/> qualified by the "urn:xmpp:delay" namespace (as defined in <xref target="XEP-0203"/>) with the attribute 'stamp' set to the UTC date and time value N<vspace blankLines="1"/></t>
<t>The plaintext stanza S<vspace blankLines="1"/></t>
</list>
</t>
<t>Converts the forwarding envelope (M) to a UTF-8 encoded string (M'), optionallly removing line breaks and other insignificant whitespace between elements and attributes, i.e. M' = UTF8-encode(M). We call M' a "stanza-string" because for purposes of encryption and decryption it is treated not as XML but as an opaque string (this avoids the need for complex canonicalization of the XML input).<vspace blankLines="1"/></t>
<t>Generates a Content Master Key (CMK). The CMK MUST have a length at least equal to that required by the content encryption algorithm in use and MUST be generated randomly. See <xref target="RFC4086"/> for considerations on generating random values.<vspace blankLines="1"/></t>
<t>Generates any additional unprotected block cipher factors (IV); e.g., initialization vector/nonce. A sending agent MUST ensure that no two sets of factors are used with the same CMK, and SHOULD NOT reuse such factors for other stanzas.<vspace blankLines="1"/></t>
<t>Performs the message encryption steps from <xref target='JOSE-JWE'/> to generate the JWE Header (H), JWE Encrypted Key (E), JWE Ciphertext (C), and JWE Integrity Value (I); using the following inputs:<vspace blankLines="1"/>
<list style="symbols">
<t>The 'alg' property is set to an appropriate key wrapping algorithm (e.g., "A256KW" or "A128KW"); recipients use 'keyreq' in <xref target='keyreq'/> to obtain the SMK.<vspace blankLines="1"/></t>
<t>The 'enc' property is set to the intended content encryption algorithm.<vspace blankLines="1"/></t>
<t>SMK as the key for CMK Encryption.<vspace blankLines="1"/></t>
<t>CMK as the JWE Content Master Key.<vspace blankLines="1"/></t>
<t>IV as the JWE Initialization Vector.<vspace blankLines="1"/></t>
<t>M' as the plaintext content to encrypt.<vspace blankLines="1"/></t>
</list>
</t>
<t>Constructs an <e2e/> element qualified by the "urn:ietf:params:xml:ns:xmpp-e2e:5" namespace as follows:<vspace blankLines="1"/>
<list style="symbols">
<t>The attribute 'id' set to the identifier value SID.<vspace blankLines="1"/></t>
<t>The child element <header/> qualified by the "urn:ietf:params:xml:ns:xmpp-e2e:5" namespace and with XML character data as H, encoded base64url as per <xref target='RFC4648'/>.<vspace blankLines="1"/></t>
<t>The child element <cmk/> qualified by the "urn:ietf:params:xml:ns:xmpp-e2e:5" namespace and with XML character as E, encoded base64url as per <xref target='RFC4648'/>.<vspace blankLines="1"/></t>
<t>The child element <iv/> qualified by the "urn:ietf:params:xml:ns:xmpp-e2e:5" namespace and with XML character as IV, encoded base64url as per <xref target='RFC4648'/>.<vspace blankLines="1"/></t>
<t>The child element <data/> qualified by the "urn:ietf:params:xml:ns:xmpp-e2e:5" namespace and with XML character data as C, encoded base64url as per <xref target='RFC4648'/>.<vspace blankLines="1"/></t>
<t>The child element <mac/> qualified by the "urn"ietf:params:xml:ns:xmpp-e2e:4" namespace and with XML character data as I, encoded base64url as per <xref target='RFC4648'/>.<vspace blankLines="1"/></t>
</list>
</t>
<t>Sends the <e2e/> element as the payload of a stanza that SHOULD match the stanza from step 1 in kind (e.g., <message/>), type (e.g., "chat"), and addressing (e.g., to="romeo@montague.net" from="juliet@capulet.net/balcony"). If the original stanza (S) has a value for the "id" attribute, this stanza MUST NOT use the same value for its "id" attribute.<vspace blankLines="1"/></t>
</list>
</t>
</section>
<section title="Example - Securing a Message" anchor="encrypt-example-msg">
<t>NOTE: unless otherwise indicated, all line breaks are included for readability.</t>
<t>The sending agent begins with the plaintext version of the <message/> stanza 'S':</t>
<figure>
<artwork><![CDATA[
<message xmlns='jabber:client'
from='juliet@capulet.lit/balcony'
to='romeo@montegue.lit'
type='chat'>
<thread>35740be5-b5a4-4c4e-962a-a03b14ed92f4</thread>
<body>
But to be frank, and give it thee again.
And yet I wish but for the thing I have.
My bounty is as boundless as the sea,
My love as deep; the more I give to thee,
The more I have, for both are infinite.
</body>
</message>
]]></artwork>
</figure>
<t>and the following prerequisites:
<list style="symbols">
<t>Sender JID as "juliet@capulet.lit/balcony"<vspace blankLines="1"/></t>
<t>Recipient JID as "romeo@montegue.lit"<vspace blankLines="1"/></t>
<t>Session Master Key 'SMK' as (base64 encoded) "xWtdjhYsH4Va_9SfYSefsJfZu03m5RrbXo_UavxxeU8"<vspace blankLines="1"/></t>
<t>SMK identifier SID as "835c92a8-94cd-4e96-b3f3-b2e75a438f92"<vspace blankLines="1"/></t>
</list>
</t>
<t>The sending agent performs steps 1, 2, and 3 to generate the envelope:</t>
<figure>
<artwork><![CDATA[
<forwarded xmlns='urn:xmpp:forward:0'>
<delay xmlns='urn:xmpp:delay'
stamp='1492-05-12T20:07:37.012Z'/>
<message xmlns='jabber:client'
from='juliet@capulet.lit/balcony'
to='romeo@montegue.lit'
type='chat'>
<thread>35740be5-b5a4-4c4e-962a-a03b14ed92f4</thread>
<body>
But to be frank, and give it thee again.
And yet I wish but for the thing I have.
My bounty is as boundless as the sea,
My love as deep; the more I give to thee,
The more I have, for both are infinite.
</body>
</message>
</forwarded>
]]></artwork>
</figure>
<t>Then the sending agent performs steps 4 through 7 (with Content Master Key as "upIjc_ePSomSETgi0DEnXsoT8ZEGf0QxsSHr_eDZRnlkJAJBFyenb6tm1WDAoqFD7-BHBtWqO5hOJlj2oxlDwQ", base64url encoded) to generate the <xref target="JOSE-JWE"/> outputs:</t>
<figure>
<preamble>JWE Header</preamble>
<artwork><![CDATA[
{
"alg":"A256KW",
"enc":"A256CBC+HS512",
"kid":"835c92a8-94cd-4e96-b3f3-b2e75a438f92"
}
]]></artwork>
</figure>
<figure>
<preamble>JWE Encrypted Key</preamble>
<artwork><![CDATA[
4ui5xwE1gEYjuptNgSIaMFlwWrAOxMqBkaplTxeJ6b2iT8kQP2HHy5PYpqqmDxl
QgT5I5rO9mgAD7AUJ9Lx35fGdi5CMiRww
]]></artwork>
</figure>
<figure>
<preamble>JWE Initialization Vector</preamble>
<artwork><![CDATA[
B7waCj2vF_sLaJfe-1GHrA
]]></artwork>
</figure>
<figure>
<preamble>JWE Ciphertext</preamble>
<artwork><![CDATA[
UYbe-ziNGBL74581rynr9MWu0Ble_6M5LFCH9xOYXgALtlDih28Ilmf-Rs68uaZ
sOND-7Ii9zK4H4XBwJjxaUlDGChZPWdwotRZdQKt9ZLpiQmjkzrQgKVQqyexP6m
qhfWRHutEKgs6vR32O2P98J-4LAWoUza5qYCZHP5NCogLUBVKi-v-vGpHDKBG_S
w3ejHSXuZOEZtyXShL2d6EXOhEzft8ViaTUKhiBCLz1q39hI5TsPdS7NPHGQDUX
Db_gSw8yVCiJgxcSbfWJKj9v_zIZgxawZby6-qif7vTIizluirnSTRO-5-2xM_n
sJEpG7ZOqofzp_WKLPkOQfa8roYGp61R5BK2M3q9LKM6y1XlMrtYFyPWH70bVPC
S_kOMrrn_48G7zmPEl-2SZWrBj4llu0oPzO2EU4uh3ipb_xUwkPPQfTkwxEdcdl
Cbi4FFIQtw81_7bPwZ3m799O_-aPspkk4uFn_cKayeN3XKf8T-i9pYPWYEOugGq
GU3H0I-jfwvqt2K6GGctoXWD6-d56WFlLhv4v6qGPT5C30vO-xM22BU9nwc-rff
4Q7cFBBM_7ciZrrTQf_PBjBhWS_pTYsmIUL-h7dwhcgQ1LEdgpqAWbZ23aMDWx-
RSQSkRY6OlPYKkbrXUbXHWxlgb5B76eA
]]></artwork>
</figure>
<figure>
<preamble>JWE Integrity Value</preamble>
<artwork><![CDATA[
G5csTEYKIXipYM1Ey4_4JSUeHpgpd8lMvYxTHwPvSd7w916w0Q8VQekY1tz8VnA
DJ751V6YiJ295_3jQUphxmQ
]]></artwork>
</figure>
<t>Then the sending agent performs steps 8 and 9, and sends the following:</t>
<figure>
<artwork><![CDATA[
<message xmlns='jabber:client'
from='juliet@capulet.lit/balcony'
id='fJZd9WFIIwNjFctT'
to='romeo@montegue.lit'
type='chat'>
<e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e:5'
id='835c92a8-94cd-4e96-b3f3-b2e75a438f92'>
<header>
eyJhbGciOiJBMjU2S1ciLCJlbmMiOiJBMjU2Q0JDK0hTNTEyIiwia2lkI
joiODM1YzkyYTgtOTRjZC00ZTk2LWIzZjMtYjJlNzVhNDM4ZjkyIn0
</header>
<cmk>
4ui5xwE1gEYjuptNgSIaMFlwWrAOxMqBkaplTxeJ6b2iT8kQP2HHy5PYp
qqmDxlQgT5I5rO9mgAD7AUJ9Lx35fGdi5CMiRww
</cmk>
<iv>
B7waCj2vF_sLaJfe-1GHrA
</iv>
<data>
UYbe-ziNGBL74581rynr9MWu0Ble_6M5LFCH9xOYXgALtlDih28Ilmf-R
s68uaZsOND-7Ii9zK4H4XBwJjxaUlDGChZPWdwotRZdQKt9ZLpiQmjkzr
QgKVQqyexP6mqhfWRHutEKgs6vR32O2P98J-4LAWoUza5qYCZHP5NCogL
UBVKi-v-vGpHDKBG_Sw3ejHSXuZOEZtyXShL2d6EXOhEzft8ViaTUKhiB
CLz1q39hI5TsPdS7NPHGQDUXDb_gSw8yVCiJgxcSbfWJKj9v_zIZgxawZ
by6-qif7vTIizluirnSTRO-5-2xM_nsJEpG7ZOqofzp_WKLPkOQfa8roY
Gp61R5BK2M3q9LKM6y1XlMrtYFyPWH70bVPCS_kOMrrn_48G7zmPEl-2S
ZWrBj4llu0oPzO2EU4uh3ipb_xUwkPPQfTkwxEdcdlCbi4FFIQtw81_7b
PwZ3m799O_-aPspkk4uFn_cKayeN3XKf8T-i9pYPWYEOugGqGU3H0I-jf
wvqt2K6GGctoXWD6-d56WFlLhv4v6qGPT5C30vO-xM22BU9nwc-rff4Q7
cFBBM_7ciZrrTQf_PBjBhWS_pTYsmIUL-h7dwhcgQ1LEdgpqAWbZ23aMD
Wx-RSQSkRY6OlPYKkbrXUbXHWxlgb5B76eA
</data>
<mac>
G5csTEYKIXipYM1Ey4_4JSUeHpgpd8lMvYxTHwPvSd7w916w0Q8VQekY1
tz8VnADJ751V6YiJ295_3jQUphxmQ
</mac>
</e2e>
</message>
]]></artwork>
</figure>
</section>
</section>
<section title="Decrypting XMPP Stanzas" anchor="decrypt">
<section title="Protocol Not Understood" anchor="decrypt-not-understood">
<t>If the receiving agent does not understand the protocol, it MUST do one and only one of the following: (1) ignore the <e2e/> extension, (2) ignore the entire stanza, or (3) return a <service-unavailable/> error to the sender, as described in <xref target="RFC6120"/>.</t>
<t>NOTE: If the inbound stanza is an <iq/>, the receiving agent MUST return an error to the sending agent, to comply with the exchanging of IQ stanzas in <xref target="RFC6121"/>.</t>
</section>
<section title="Process" anchor="decrypt-process">
<t>Upon receipt of an encrypted stanza, the receiving agent performs the following:
<list style="numbers">
<t>Determines if a valid SMK is available, associated with the SID specified by the 'id' attribute value of the <e2e/> element and the sending agent JID specified by the 'from' attribute of the wrapping stanza. If the receiving agent does not already have the CMK, it requests it according to <xref target="keyreq"/>.<vspace blankLines="1"/></t>
<t>Performs the message decryption steps from <xref target="JOSE-JWE"/> to generate the plaintext forwarding envelope string M', using the following inputs:<vspace blankLines="1"/>
<list style="symbols">
<t>The JWE Header H from the <header/> element's character data content.<vspace blankLines="1"/></t>
<t>The JWE Encrypted Key from the <cmk/> element's character data content.<vspace blankLines="1"/></t>
<t>The JWE Initialization Vector/Nonce from the <iv/> element's character data content.<vspace blankLines="1"/></t>
<t>The JWE Ciphertext C from the <data/> element's character data content.<vspace blankLines="1"/></t>
<t>The JWE Integrity Value I from the <mac/> element's character data content.<vspace blankLines="1"/></t>
</list>
</t>
<t>Converts the forwarding envelope UTF-8 ecoded string M' into XML element M.<vspace blankLines="1"/></t>
<t>Obtains the UTC date and time N from the <delay/> child element, and verifies it is within the accepted range, as specified in <xref target="timestamps"/>.<vspace blankLines="1"/></t>
<t>Obtains the plaintext stanza S, which is a child element node of M; the stanza MUST be fully qualified with proper namespace declarations for XMPP stanzas, to help distinguish it from other content within M.<vspace blankLines="1"/>.</t>
</list>
</t>
</section>
<section title="Insufficient Information" anchor="decrypt-insufficient-info">
<t>At step 1, if the receiving agent is unable to obtain the CMK, or the receiving agent could not otherwise determine the additional information, it MAY return a <bad-request/> error to the sending agent (as described in <xref target="RFC6120"/>), optionally supplemented by an application-specific error condition element of <insufficient-information/>:</t>
<figure>
<artwork><![CDATA[
<message xmlns='jabber:client'
from='juliet@capulet.lit/balcony'
id='fJZd9WFIIwNjFctT'
to='romeo@montegue.lit/garden'
type='chat'>
<e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e:5'
id='835c92a8-94cd-4e96-b3f3-b2e75a438f92'>
<header>[XML character data]</header>
<cmk>[XML character data]</cmk>
<iv>[XML character data]</iv>
<data>[XML character data]</data>
<mac>[XML character data]</mac>
</e2e>
<error type='modify'>
<bad-request
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<insufficient-information
xmlns='urn:ietf:params:xml:ns:xmpp-e2e:5'/>
</error>
</message>
]]></artwork>
</figure>
<t>In addition to returning an error, the receiving agent SHOULD NOT present the stanza to the intended recipient (human or application) and SHOULD provide some explicit alternate processing of the stanza (which MAY be to display a message informing the recipient that it has received a stanza that cannot be decrypted).</t>
</section>
<section title="Failed Decryption" anchor="decrypt-failed">
<t>At step 2, if the receiving agent is unable to successfully decrypt the stanza, the receiving agent SHOULD return a <bad-request/> error to the sending agent (as described in <xref target="RFC6120"/>), optionally supplemented by an application-specific error condition element of <decryption-failed/> (previously defined in <xref target="RFC3923"/>):</t>
<figure>
<artwork><![CDATA[
<message xmlns='jabber:client'
from='juliet@capulet.lit/balcony'
id='fJZd9WFIIwNjFctT'
to='romeo@montegue.lit/garden'
type='chat'>
<e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e:5'
id='835c92a8-94cd-4e96-b3f3-b2e75a438f92'>
<header>[XML character data]</header>
<cmk>[XML character data]</cmk>
<iv>[XML character data]</iv>
<data>[XML character data]</data>
<mac>[XML character data]</mac>
</e2e>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<decryption-failed xmlns='urn:ietf:params:xml:ns:xmpp-e2e:5'/>
</error>
</message>
]]></artwork>
</figure>
<t>In addition to returning an error, the receiving agent SHOULD NOT present the stanza to the intended recipient (human or application) and SHOULD provide some explicit alternate processing of the stanza (which MAY be to display a message informing the recipient that it has received a stanza that cannot be decrypted).</t>
</section>
<section title="Timestamp Not Acceptable" anchor="decrypt-timestamps">
<t>At step 4, if the stanza is successfully decrypted but the timestamp fails the checks outlined in <xref target="timestamps"/>, the receiving agent MAY return a <not-acceptable/> error to the sender (as described in <xref target="RFC6120"/>), optionally supplemented by an application-specific error condition element of <bad-timestamp/> (previously defined in <xref target="RFC3923"/>):</t>
<figure>
<artwork><![CDATA[
<message xmlns='jabber:client'
from='juliet@capulet.lit/balcony'
id='fJZd9WFIIwNjFctT'
to='romeo@montegue.lit/garden'
type='chat'>
<e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e:5'
id='835c92a8-94cd-4e96-b3f3-b2e75a438f92'>
<header>[XML character data]</header>
<cmk>[XML character data]</cmk>
<iv>[XML character data]</iv>
<data>[XML character data]</data>
<mac>[XML character data]</mac>
</e2e>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<bad-timestamp xmlns='urn:ietf:params:xml:ns:xmpp-e2e:5'/>
</error>
</message>
]]></artwork>
</figure>
</section>
<section title="Successful Decryption" anchor="decrypt-success">
<t>If the receiving agent successfully decrypted the payload, it MUST NOT return a stanza error.</t>
<t>If the payload is an <iq/> of type "get" or "set", and the response to this <iq/> is of type "error", the receiving agent MUST send the encrypted response wrapped in an <iq/> of type "result", to prevent exposing information about the payload.</t>
</section>
</section>
<section title="Requesting Session Keys" anchor="keyreq">
<t>Because of the dynamic nature of XMPP stanza routing, the protocol does not exchange session keys as part of the encrypted stanza. Instead, a separate protocol is used by receiving agents to request a particular session key from the sending agent.</t>
<section title="Request Process" anchor="keyreq-process-request">
<t>Before a SMK can be requested, the receiving agent MUST have at least one public key for which it also has the private key.</t>
<t>To request a SMK, the receiving agent performs the following:<vspace blankLines="1"/>
<list style="numbers">
<t>Constructs a <xref target="JOSE-JWK"/> JWK Set (KS), containing information about each public key the requesting agent wishes to use. Each key SHOULD include a value for the property 'kid' which uniquely identifies it within the context of all provided keys. Each key MUST include a value for the property 'kid' if any two keys use the same algorithm.<vspace blankLines="1"/></t>
<t>Constructs a <keyreq/> element qualified by the "urn:ietf:params:xml:ns:xmpp-e2e:5" namespace as follows:<vspace blankLines="1"/>
<list style="symbols">
<t>The attribute 'id' set to the SMK identifier value SID.<vspace blankLines="1"/></t>
<t>The child element <pkey/> qualified by the "urn:ietf:params:xml:ns:xmpp-e2e:5" namespace and with XML character data as KS, encoded base64url as pre <xref target='RFC4648'/>.<vspace blankLines="1"/></t>
</list>
</t>
<t>Sends the <keyreq/> element as the payload of an <iq/> stanza with the attribute 'type' set to "get", the attribute 'to' set to the full JID of the original encrypted stanza's sender, and the attribute 'id' set to an opaque string value the receiving agent uses to track the <iq/> response.<vspace blankLines="1"/></t>
</list>
</t>
</section>
<section title="Accept Process" anchor="keyreq-process-accept">
<t>If the sending agent approves the request, it performs the following steps:<vspace blankLines="1"/>
<list style="numbers">
<t>Generate a JSON Web Key (JWK) representing the SMK (according to <xref target="JOSE-JPSK"/>):<vspace blankLines="1"/>
<list style="symbols">
<t>The "kty" parameter MUST be "oct".<vspace blankLines="1"/></t>
<t>The "kid" parameter MUST be the SID.<vspace blankLines="1"/></t>
<t>The "k" parameter MUST be the SMK, encoded as base64url.<vspace blankLines="1"/></t>
<t>The "use" parameter, if present, MUST be set to the algorithm in use for encrypting messages from <xref target="encrypt"/>.<vspace blankLines="1"/></t>
<t>The "use" parameter, if present, MUST be set to "enc".<vspace blankLines="1"/></t>
</list>
</t>
<t>Chooses a key (PK) from the keys provided via KS, and notes its identifier value 'kid'.<vspace blankLines="1"/></t>
<t>Protects the SMK using the process outlined in <xref target="JOSE-KEYPROTECT"/> to generate the JWE Header (H), JWE Encrypted Key (E), JWE Initialization Vector (IV), JWE Ciphertext (C), and JWE Integrity Value (I); using the following inputs:<vspace blankLines="1"/>
<list style="symbols">
<t>The 'alg' property is set to an algorithm appropriate for the chosen PK (e.g., "RSA-OAEP" for a "RSA" key).<vspace blankLines="1"/></t>
<t>The 'enc' property is set to the intended content encryption algorithm.<vspace blankLines="1"/></t>
<t>A randomly generated CMK. See <xref target="RFC4086"/> for considerations on generating random values.<vspace blankLines="1"/></t>
<t>A randomly generated initialization vector. See <xref target="RFC4086"/> for considerations on generating random values.<vspace blankLines="1"/></t>
<t>SMK, formatted as a JWK as above.<vspace blankLines="1"/></t>
</list>
</t>
<t>Constructs a <keyreq/> element qualified by the "urn:ietf:params:xml:ns:xmpp-e2e:5" namespace as follows:<vspace blankLines="1"/>
<list style="symbols">
<t>The attribute 'id' set to the SMK identifier SID.<vspace blankLines="1"/></t>
<t>The child element <header/> qualified by the "urn:ietf:params:xml:ns:xmpp-e2e:5" namespace and with XML character data as H, encoded base64url as per <xref target='RFC4648'/>.<vspace blankLines="1"/></t>
<t>The child element <cmk/> qualified by the "urn:ietf:params:xml:ns:xmpp-e2e:5" namespace and with XML character data as E, encoded base64url as per <xref target='RFC4648'/>.<vspace blankLines="1"/></t>
<t>The child element <iv/> qualified by the "urn:ietf:params:xml:ns:xmpp-e2e:5" namespace and with XML character data as IV, encoded base64url as per <xref target='RFC4648'/>.<vspace blankLines="1"/></t>
<t>The child element <data/> qualified by the "urn:ietf:params:xml:ns:xmpp-e2e:5" namespace and with XML character data as C, encoded base64url as per <xref target='RFC4648'/>.<vspace blankLines="1"/></t>
<t>The child element <mac/> qualified by the "urn:ietf:params:xml:ns:xmpp-e2e:5" namespace and with XML character data as I, encoded base64url as per <xref target='RFC4648'/>.<vspace blankLines="1"/></t>
</list>
</t>
<t>Sends the <keyreq/> element as the payload of an <iq/> stanza with the attribute 'type' set to "result", the attribute 'to' set to the full JID from the request <iq/>'s 'from' attribute, and the attribute 'id' set to the value of the request <iq/>'s 'id' attribute.<vspace blankLines="1"/></t>
</list>
</t>
</section>
<section title="Error Conditions" anchor="keyreq-errors">
<t>If the sending agent does not approve the request, it sends an <iq/> stanza of type "error" and containing the reason for denying the request:<vspace blankLines="1"/>
<list style="symbols">
<t><forbidden/>: the key request is made by an entity that is not authorized to decrypt stanzas from the sending agent and/or for the indicated SID.<vspace blankLines="1"/></t>
<t><item-not-found/>: the requested SID is no longer valid.<vspace blankLines="1"/></t>
<t><not-acceptable/>: the key request did not contain any keys the sending agent understands.<vspace blankLines="1"/></t>
</list>
</t>
</section>
<section title="Example of Successful Key Request" anchor="keyreq-example-success">
<t>NOTE: unless otherwise indicated, all line breaks are included for readability.</t>
<t>To begin a key request, the receiving agent performs step 1 from <xref target="keyreq-process-request"/> to generate the <xref target="JOSE-JWK"/>:</t>
<figure>
<artwork><![CDATA[
{
"keys": [{
"kty":"RSA",
"kid":"romeo@montegue.lit/garden",
"n":"vtqejkMF01h8oKEaHfHEYO0C2jM7eISbbSvNs0SNItYWO6GbjpJf
N4ldXw2vpVRdysnwU3zk6o2_SD0YCH1WgeuI0QK1knMTDdNSXx52e1c4BTw
hlA8iHuutTWmpBqesn1GNZmqB3jYsJOkVBYwCJtkB9APaBvk0itlRtizjCf
1HHnau7nGStyshgu8-srxi_d8rC5TTLSB_zT1i6fP8fwDloemXOtC0U65by
5P-1ZHxaf_bD8fpjps6gwSgdkZKMJAI0bOWZWuMpp2ntqa0wLB7Ndxb2Ijr
eog_s5ssAoSiXDVdoswSbp36ZP-1lnCk2j-vZ4qbhaFg5bZtgt-gwQ",
"e":"AQAB"
}]
}
]]></artwork>
</figure>
<t>Then the receiving agent performs step 2 to generate the <keyreq/>:</t>
<figure>
<artwork><![CDATA[
<keyreq xmlns='urn:ietf:params:xml:ns:xmpp-e2e:5'
id='835c92a8-94cd-4e96-b3f3-b2e75a438f92'>
<pkey>
eyJrZXlzIjpbeyJrdHkiOiJSU0EiLCJraWQiOiJyb21lb0Btb250ZWd1ZS5
saXQvZ2FyZGVuIiwibiI6InZ0cWVqa01GMDFoOG9LRWFIZkhFWU8wQzJqTT
dlSVNiYlN2TnMwU05JdFlXTzZHYmpwSmZONGxkWHcydnBWUmR5c253VTN6a
zZvMl9TRDBZQ0gxV2dldUkwUUsxa25NVERkTlNYeDUyZTFjNEJUd2hsQThp
SHV1dFRXbXBCcWVzbjFHTlptcUIzallzSk9rVkJZd0NKdGtCOUFQYUJ2azB
pdGxSdGl6akNmMUhIbmF1N25HU3R5c2hndTgtc3J4aV9kOHJDNVRUTFNCX3
pUMWk2ZlA4ZndEbG9lbVhPdEMwVTY1Ynk1UC0xWkh4YWZfYkQ4ZnBqcHM2Z
3dTZ2RrWktNSkFJMGJPV1pXdU1wcDJudHFhMHdMQjdOZHhiMklqcmVvZ19z
NXNzQW9TaVhEVmRvc3dTYnAzNlpQLTFsbkNrMmotdlo0cWJoYUZnNWJadGd
0LWd3USIsImUiOiJBUUFCIn1dfQ
</pkey>
</keyreq>
]]></artwork>
</figure>
<t>Then the receiving agent performs step 3 and sends the following:</t>
<figure>
<artwork><![CDATA[
<iq xmlns='jabber:client'
from='romeo@montegue.lit/garden'
id='xdJbWMA+'
to='juliet@capulet.lit/balcony'
type='get'>
<keyreq xmlns='urn:ietf:params:xml:ns:xmpp-e2e:5'
id='835c92a8-94cd-4e96-b3f3-b2e75a438f92'>
<pkey>
eyJrZXlzIjpbeyJrdHkiOiJSU0EiLCJraWQiOiJyb21lb0Btb250ZWd1Z
S5saXQvZ2FyZGVuIiwibiI6InZ0cWVqa01GMDFoOG9LRWFIZkhFWU8wQz
JqTTdlSVNiYlN2TnMwU05JdFlXTzZHYmpwSmZONGxkWHcydnBWUmR5c25
3VTN6azZvMl9TRDBZQ0gxV2dldUkwUUsxa25NVERkTlNYeDUyZTFjNEJU
d2hsQThpSHV1dFRXbXBCcWVzbjFHTlptcUIzallzSk9rVkJZd0NKdGtCO
UFQYUJ2azBpdGxSdGl6akNmMUhIbmF1N25HU3R5c2hndTgtc3J4aV9kOH
JDNVRUTFNCX3pUMWk2ZlA4ZndEbG9lbVhPdEMwVTY1Ynk1UC0xWkh4YWZ
fYkQ4ZnBqcHM2Z3dTZ2RrWktNSkFJMGJPV1pXdU1wcDJudHFhMHdMQjdO
ZHhiMklqcmVvZ19zNXNzQW9TaVhEVmRvc3dTYnAzNlpQLTFsbkNrMmotd
lo0cWJoYUZnNWJadGd0LWd3USIsImUiOiJBUUFCIn1dfQ
</pkey>
</keyreq>
</iq>
]]></artwork>
</figure>
<t>If the sending agent accepts this key request, it performs step 1 from <xref target="keyreq-process-accept"/> to generate JWK representation of the SMK:</t>
<figure>
<artwork><![CDATA[
{
"kty":"oct",
"kid":"835c92a8-94cd-4e96-b3f3-b2e75a438f92",
"oct":"xWtdjhYsH4Va_9SfYSefsJfZu03m5RrbXo_UavxxeU8"
}
]]></artwork>
</figure>
<t>Then the sending agent performs steps 2 and 3 to generate the protected SMK:</t>
<figure>
<preamble>JWE Header (before base64url encoding)</preamble>
<artwork><![CDATA[
{
"alg":"RSA-OAEP",
"enc":"A256CBC+HS512",
"kid":"romeo@montegue.lit/garden"
}
]]></artwork>
</figure>
<figure>
<preamble>JWE Encrypted Key</preamble>
<artwork><![CDATA[
UeoVeGcZP-VsLu1PVj3NNWkmmEF7H2Nl_mHWscOuT_vYn-4ub2NEnRy4dzyycgx
ny6jmRPpNiGJB6AfI4TYZvrjig5dubv4uG7phCvKYVI3uaUU58Fc9H_o-BTmNv2
rUT-RGt6YYLW97ZJp5ZcA2l-KxykcxaRYC4Sv_UOS3Kqo0sVx5u7tolE6SbMnUH
etg91Gc9pVVa1XX-wz4ZrcA6V8zf8pCtmc4WyDMFx8RYYXR_5Qvax-TzOJUL2eA
r3OQsf3KNh58WvvzcwAKTmR214QmZCxI_A5mIqoog0H0uV987P9yw1wFfsmg7z-
Y2Ed7Blp-zLOvXEQKU9FM-vjBnA
]]></artwork>
</figure>
<figure>
<preamble>JWE Initialization Vector</preamble>
<artwork><![CDATA[
eiXTO21DNqFnCTQkLAoAtA
]]></artwork>
</figure>
<figure>
<preamble>JWE Ciphertext</preamble>
<artwork><![CDATA[
e8sZiRvKLPOUjmFwOYhvrZMQYzW1yglg6mTnazJU_rF7mXTBIieNZCd7hDrlrdG
SxqqUgh6N1O2QBLygf2PtWDmHHjn1aLncx6qlGf0UOxCCXUBfBIhZgFH5YX1i3_
VSsNUDEoIKTGA21EnamOqa1A
]]></artwork>
</figure>
<figure>
<preamble>JWE Integrity Value</preamble>
<artwork><![CDATA[
WQzHj3j30Qo7VakMM42t-X1omQVGyebd3No9ZFGPQNUwEWONjIcZ89_wFBhZFdd
kc8i_qtXi-9XPmSVei3A_Jw
]]></artwork>
</figure>
<t>Then the sending agent performs step 4 to generate the <keyreq/> response:</t>
<figure>
<artwork><![CDATA[
<keyreq xmlns='urn:ietf:params:xml:ns:xmpp-e2e:5'
id='835c92a8-94cd-4e96-b3f3-b2e75a438f92'>
<header>
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZDQkMrSFM1MTIiLCJraWQ
iOiJyb21lb0Btb250ZWd1ZS5saXQvZ2FyZGVuIn0
</header>
<cmk>
UeoVeGcZP-VsLu1PVj3NNWkmmEF7H2Nl_mHWscOuT_vYn-4ub2NEnRy4dzy
ycgxny6jmRPpNiGJB6AfI4TYZvrjig5dubv4uG7phCvKYVI3uaUU58Fc9H_
o-BTmNv2rUT-RGt6YYLW97ZJp5ZcA2l-KxykcxaRYC4Sv_UOS3Kqo0sVx5u
7tolE6SbMnUHetg91Gc9pVVa1XX-wz4ZrcA6V8zf8pCtmc4WyDMFx8RYYXR
_5Qvax-TzOJUL2eAr3OQsf3KNh58WvvzcwAKTmR214QmZCxI_A5mIqoog0H
0uV987P9yw1wFfsmg7z-Y2Ed7Blp-zLOvXEQKU9FM-vjBnA
</cmk>
<iv>
eiXTO21DNqFnCTQkLAoAtA
</iv>
<data>
e8sZiRvKLPOUjmFwOYhvrZMQYzW1yglg6mTnazJU_rF7mXTBIieNZCd7hDr
lrdGSxqqUgh6N1O2QBLygf2PtWDmHHjn1aLncx6qlGf0UOxCCXUBfBIhZgF
H5YX1i3_VSsNUDEoIKTGA21EnamOqa1A
</data>
<mac>
WQzHj3j30Qo7VakMM42t-X1omQVGyebd3No9ZFGPQNUwEWONjIcZ89_wFBh
ZFddkc8i_qtXi-9XPmSVei3A_Jw
</mac>
</keyreq>
]]></artwork>
</figure>
<t>Then the sending agent performs step 5 and sends the following:</t>
<figure>
<artwork><![CDATA[
<iq xmlns='jabber:client'
from='juliet@capulet.lit/balcony'
id='xdJbWMA+'
to='romeo@montegue.lit/garden'
type='result'>
<keyreq xmlns='urn:ietf:params:xml:ns:xmpp-e2e:5'
id='835c92a8-94cd-4e96-b3f3-b2e75a438f92'>
<header>
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZDQkMrSFM1MTIiLCJraWQ
iOiJyb21lb0Btb250ZWd1ZS5saXQvZ2FyZGVuIn0
</header>
<cmk>
UeoVeGcZP-VsLu1PVj3NNWkmmEF7H2Nl_mHWscOuT_vYn-4ub2NEnRy4dzy
ycgxny6jmRPpNiGJB6AfI4TYZvrjig5dubv4uG7phCvKYVI3uaUU58Fc9H_
o-BTmNv2rUT-RGt6YYLW97ZJp5ZcA2l-KxykcxaRYC4Sv_UOS3Kqo0sVx5u
7tolE6SbMnUHetg91Gc9pVVa1XX-wz4ZrcA6V8zf8pCtmc4WyDMFx8RYYXR
_5Qvax-TzOJUL2eAr3OQsf3KNh58WvvzcwAKTmR214QmZCxI_A5mIqoog0H
0uV987P9yw1wFfsmg7z-Y2Ed7Blp-zLOvXEQKU9FM-vjBnA
</cmk>
<iv>
eiXTO21DNqFnCTQkLAoAtA
</iv>
<data>
e8sZiRvKLPOUjmFwOYhvrZMQYzW1yglg6mTnazJU_rF7mXTBIieNZCd7hDr
lrdGSxqqUgh6N1O2QBLygf2PtWDmHHjn1aLncx6qlGf0UOxCCXUBfBIhZgF
H5YX1i3_VSsNUDEoIKTGA21EnamOqa1A
</data>
<mac>
WQzHj3j30Qo7VakMM42t-X1omQVGyebd3No9ZFGPQNUwEWONjIcZ89_wFBh
ZFddkc8i_qtXi-9XPmSVei3A_Jw
</mac>
</keyreq>
</iq>
]]></artwork>
</figure>
</section>
</section>
<section title="Inclusion and Checking of Timestamps" anchor="timestamps">
<t>Timestamps are included to help prevent replay attacks. All timestamps MUST conform to <xref target="XEP-0082"/> and be presented as UTC with no offset, and SHOULD include the seconds and fractions of a second to three digits. Absent a local adjustment to the sending agent's perceived time or the underlying clock time, the sending agent MUST ensure that the timestamps it sends to the receiver increase monotonically (if necessary by incrementing the seconds fraction in the timestamp if the clock returns the same time for multiple requests). The following rules apply to the receiving agent:</t>
<t>
<list style="symbols">
<t>It MUST verify that the timestamp received is within five minutes of the current time, except as described below for offline messages.<vspace blankLines="1"/></t>
<t>It SHOULD verify that the timestamp received is greater than any timestamp received in the last 10 minutes which passed the previous check.<vspace blankLines="1"/></t>
<t>If any of the foregoing checks fails, the timestamp SHOULD be presented to the receiving entity (human or application) marked as "old timestamp", "future timestamp", or "decreasing timestamp", and the receiving entity MAY return a stanza error to the sender.</t>
</list>
</t>
<t>The foregoing timestamp checks assume that the recipient is online when the message is received. However, if the recipient is offline then the server might store the message for delivery when the recipient is next online (offline storage does not apply to <iq/> or <presence/> stanzas, only <message/> stanzas). As described in <xref target="XEP-0160"/>, when sending an offline message to the recipient, the server SHOULD include delayed delivery data as specified in <xref target="XEP-0203"/> so that the recipient knows that this is an offline message and also knows the original time of receipt at the server. In this case, the recipient SHOULD verify that the timestamp received in the encrypted message is within five minutes of the time stamped by the recipient's server in the <delay/> element.</t>
</section>
<section title="Interaction with Stanza Semantics" anchor="interact">
<t>The following limitations and caveats apply:</t>
<t>
<list style="symbols">
<t>Undirected <presence/> stanzas SHOULD NOT be encrypted. Such stanzas are delivered to anyone the sender has authorized, and can generate a large volume of key requests.<vspace blankLines="1"/></t>
<t>Stanzas directed to multiplexing services (e.g., multi-user chat) SHOULD NOT be encrypted, unless the sender has established an acceptable trust relationship with the multiplexing service.<vspace blankLines="1"/></t>
</list>
</t>
</section>
<section title="Mandatory-to-Implement Cryptographic Algorithms" anchor="mti">
<t>All algorithms that MUST be implemented for <xref target="JOSE-JWE"/> also MUST be implemented for this specification.</t>
</section>
<!--
<section title="Certificates" anchor="certs">
<t>To participate in end-to-end encryption using the methods defined in this document, a client needs to possess an X.509 certificate <xref target="PKIX"/>. It is expected that many clients will generate their own (self-signed) certificates rather than obtain a certificate issued by a certification authority (CA). In any case the certificate MUST include an XMPP address that is represented using the ASN.1 Object Identifier "id-on-xmppAddr" as specified in Section 5.1.1 of <xref target="RFC6120"/>.</t>
</section>
-->
<section title="Security Considerations" anchor="security">
<section title="Storage of Encrypted Stanzas" anchor="security-storage">
<t>The recipient's server might store any <message/> stanzas received until the recipient is next available; this duration could be anywhere from a few minutes to several months.</t>
</section>
<section title="Re-use of Session Master Keys" anchor="security-smk">
<t>A sender SHOULD NOT use the same SMK for stanzas intended for different recipients, as determined by the localpart and domainpart of the recipient's JID.</t>
<t>A sender MAY re-use a SMK for several stanzas to the same recipient. In this case, the SID remains the same, but the sending agent MUST generate a new CMK and IV for each encrypted stanza. The sender SHOULD periodically generate a new SMK; however, this specification does not mandate any specific algorithms or processes.</t>
<t>In the case of <message/> stanzas, a sending agent might generate a new SMK each time it generates a new ThreadID, as outlined in <xref target="XEP-0201"/>.</t>
</section>
</section>
<section title="IANA Considerations" anchor="iana">
<section title="XML Namespace Name for e2e Data in XMPP" anchor="iana-ns-e2e">
<t>A URN sub-namespace of encrypted content for the Extensible Messaging and Presence Protocol (XMPP) is defined as follows.</t>
<t>
<list style="hanging">
<t hangText="URI:">urn:ietf:params:xml:ns:xmpp-e2e:5</t>
<t hangText="Specification:">RFC XXXX</t>
<t hangText="Description:">This is an XML namespace name of encrypted content for the Extensible Messaging and Presence Protocol as defined by RFC XXXX.</t>
<t hangText="Registrant Contact:">IESG, <iesg@ietf.org></t>
</list>
</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="E2E-REQ">
<front>
<title>Requirements for End-to-End Encryption in the Extensible Messaging and Presence Protocol (XMPP)</title>
<author initials="P" surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
</author>
<date month="March" day="22" year="2010"/>
<abstract>
<t>This document describes requirements for end-to-end encryption in the Extensible Messaging and Presence Protocol (XMPP).</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-saintandre-xmpp-e2e-requirements-01"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-saintandre-xmpp-e2e-requirements-01.txt"/>
</reference>
<reference anchor="JOSE-JWA">
<front>
<title>JSON Web Algorithms (JWA)</title>
<author initials="M." surname="Jones" fullname="Michael B. Jones">
<organization>Microsoft</organization>
<address>
<email>mjb@microsoft.com</email>
</address>
</author>
<date year="2012" month="December"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-jose-json-web-algorithms-08"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-algorithms-08.txt"/>
</reference>
<reference anchor="JOSE-JWE">
<front>
<title>JSON Web Encryption (JWE)</title>
<author initials="M." surname="Jones" fullname="Michael B. Jones">
<organization>Microsoft</organization>
<address>
<email>mjb@microsoft.com</email>
</address>
</author>
<author initials="E." surname="Rescola" fullname="Eric Rescola">
<organization>RTFM, Inc.</organization>
<address>
<email>ekr@rtfm.com</email>
</address>
</author>
<author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
<organization>Cisco Systems, Inc.</organization>
<address>
<email>jhildebr@cisco.com</email>
</address>
</author>
<date year="2012" month="December"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-jose-json-web-encryption-08"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-encryption-08.txt"/>
</reference>
<reference anchor="JOSE-JWK">
<front>
<title>JSON Web Key (JWK)</title>
<author initials="M." surname="Jones" fullname="Michael B. Jones">
<organization>Microsoft</organization>
<address>
<email>mjb@microsoft.com</email>
</address>
</author>
<date year="2012" month="December"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-jose-json-web-key-08"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-key-08.txt"/>
</reference>
<reference anchor="JOSE-JPSK">
<front>
<title>JSON Private and Symmetric Key</title>
<author initials="M." surname="Jones" fullname="Michael B. Jones">
<organization>Microsoft</organization>
<address>
<email>mjb@microsoft.com</email>
</address>
</author>
<date year="2012" month="December"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-jones-jose-json-private-and-symmetric-key-00"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-jones-jose-json-private-and-symmetric-key-00.txt"/>
</reference>
<reference anchor="JOSE-KEYPROTECT">
<front>
<title>Using JSON Web Encryption (JWE) for Protecting JSON Web Key (JWK) Objects</title>
<author initials="M." surname="Miller" fullname="Matthew Miller">
<organization>Cisco Systems, Inc.</organization>
<address>
<email>mamille2@cisco.com</email>
</address>
</author>
<date year="2013" month="February"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-miller-jose-jwe-protected-jwk-00"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-miller-jose-jwe-protected-jwk-00.txt"/>
</reference>
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>-</email>
</address>
</author>
<date month="March" year="1997"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:
<list><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 RFC 2119.</t></list>
</t>
<t>Note that the force of these words is modified by the requirement level of the document in which they are used.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
</reference>
<reference anchor="RFC4648">
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author initials="S." surname="Josefsson" fullname="S. Josefsson">
<organization/>
</author>
<date year="2006" month="October"/>
<abstract>
<t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4648"/>
<format type="TXT" octets="35491" target="ftp://ftp.isi.edu/in-notes/rfc4648.txt"/>
</reference>
<reference anchor="RFC4949">
<front>
<title>Internet Security Glossary, Version 2</title>
<author initials="R." surname="Shirey" fullname="R. Shirey">
<organization/>
</author>
<date year="2007" month="August"/>
<abstract>
<t>This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4949"/>
<format type="TXT" octets="867626" target="ftp://ftp.isi.edu/in-notes/rfc4949.txt"/>
</reference>
<reference anchor="RFC6120">
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco</organization>
<address>
<email>psaintan@cisco.com</email>
</address>
</author>
<date month="March" year="2011"/>
</front>
<seriesInfo name="RFC" value="6120"/>
<format type="TXT" target="http://tools.ietf.org/rfc/rfc6120.txt"/>
</reference>
<reference anchor="RFC6121">
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco</organization>
<address>
<email>psaintan@cisco.com</email>
</address>
</author>
<date month="March" year="2011"/>
</front>
<seriesInfo name="RFC" value="6121"/>
<format type="TXT" target="http://tools.ietf.org/rfc/rfc6121.txt"/>
</reference>
<reference anchor="XEP-0030">
<front>
<title>Service Discovery</title>
<author initials="R." surname="Eatmon" fullname="Ryan Eatmon">
<organization/>
<address>
<email>reatmon@jabber.org</email>
</address>
</author>
<author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
<organization>Cisco</organization>
<address>
<email>jhildebr@cisco.com</email>
</address>
</author>
<author initials="P." surname="Millard" fullname="Peter Millard">
<organization/>
<address/>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<date month="June" year="2006"/>
</front>
<seriesInfo name="XSF XEP" value="0030"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0030.html"/>
</reference>
<reference anchor="XEP-0082">
<front>
<title>XMPP Date and Time Profiles</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<date month="May" year="2003"/>
</front>
<seriesInfo name="XSF XEP" value="0082"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0082.html"/>
</reference>
<reference anchor="XEP-0115">
<front>
<title>Entity Capabilities</title>
<author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
<organization>Cisco</organization>
<address>
<email>jhildebr@cisco.com</email>
</address>
</author>
<author initials="R." surname="Troncon" fullname="Remko Troncon">
<organization/>
<address>
<uri>http://el-tramo.be/</uri>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<date month="February" year="2008"/>
</front>
<seriesInfo name="XSF XEP" value="0115"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0115.html"/>
</reference>
<reference anchor="XEP-0203">
<front>
<title>Delayed Delivery</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<date day="15" month="September" year="2009"/>
</front>
<seriesInfo name="XSF XEP" value="0203"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0203.html"/>
</reference>
<reference anchor="XEP-0297">
<front>
<title>Stanza Forwarding</title>
<author initials="M." surname="Wild" fullname="Matthew Wild">
<organization/>
<address>
<email>me@matthewwild.co.uk</email>
</address>
</author>
<author initials="K." surname="Smith" fullname="Kevin Smith">
<organization/>
<address>
<email>kevin@kismith.co.uk</email>
</address>
</author>
<date day="11" month="July" year="2012"/>
</front>
<seriesInfo name="XSF XEP" value="0297"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0297.html"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC3610">
<front>
<title>Counter with CBC-MAC (CCM)</title>
<author initials="D." surname="Whiting" fullname="Doug Whiting">
<organization>Hifn</organization>
</author>
<author initials="R." surname="Housley" fullname="Russell Housley">
<organization>Vigil Security, LLC</organization>
</author>
<author initials="N." surname="Ferguson" fullname="Niels Ferguson">
<organization>MacFergus BV</organization>
</author>
<date year="2003" month="September"/>
</front>
<seriesInfo name="RFC" value="3923"/>
<format type="TXT" octets="51828" target="ftp://ftp.isi.edu/in-notes/rfc3923.txt"/>
</reference>
<reference anchor="RFC3923">
<front>
<title>End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)</title>
<author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre">
<organization>Jabber Software Foundation</organization>
</author>
<date year="2004" month="October"/>
</front>
<seriesInfo name="RFC" value="3923"/>
<format type="TXT" octets="51828" target="ftp://ftp.isi.edu/in-notes/rfc3923.txt"/>
</reference>
<reference anchor="RFC4086">
<front>
<title>Randomness Requirements for Security</title>
<author initials="D." surname="Eastlake" fullname="Donald E. Eastlake 3rd">
<organization>Motorola Laboratories</organization>
<address>
<email>donald.eastlake@motorola.com</email>
</address>
</author>
<author initials="J." surname="Schiller" fullname="Jeffrey I. Schiller">
<organization>MIT, Room E30-311</organization>
<address>
<email>jis@mit.edu</email>
</address>
</author>
<author initials="S." surname="Crocker" fullname="Steve Crocker">
<organization/>
<address>
<email>steve@stevecrocker.com</email>
</address>
</author>
<date month="June" year="2005"/>
</front>
<seriesInfo name="RFC" value="4086"/>
<format type="TXT" target="http://tools.ietf.org/rfc/rfc4086.txt"/>
</reference>
<reference anchor="XEP-0160">
<front>
<title>Best Practices for Handling Offline Messages</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<date day="24" month="January" year="2006"/>
</front>
<seriesInfo name="XSF XEP" value="0160"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0160.html"/>
</reference>
<reference anchor="XEP-0201">
<front>
<title>Best Practices for Message Threads</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<author initials="I." surname="Paterson" fullname="Ian Paterson">
<organization/>
<address>
<email>ian.paterson@clientside.co.uk</email>
</address>
</author>
<author initials="K." surname="Smith" fullname="Kevin Smith">
<organization/>
<address>
<email>kevin@doomsong.co.uk</email>
</address>
</author>
<date day="29" month="November" year="2010"/>
</front>
<seriesInfo name="XSF XEP" value="0203"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0203.html"/>
</reference>
</references>
<section title="Schema for urn:ietf:params:xml:ns:xmpp-e2e:5" anchor="schemas-e2e">
<t>The following XML schema is descriptive, not normative.</t>
<figure>
<artwork><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-e2e:5'
xmlns='urn:ietf:params:xml:ns:xmpp-e2e:5'
elementFormDefault='qualified'>
<xs:element name='e2e'>
<xs:complexType>
<xs:attribute name='id' type='xs:string' use='required'/>
<xs:sequence>
<xs:element ref='header' minOccurs='1' maxOccurs='1'/>
<xs:element ref='cmk' minOccurs='1' maxOccurs='1'/>
<xs:element ref='iv' minOccurs=1' maxOccurs='1'/>
<xs:element ref='data' minOccurs='1' maxOccurs='1'/>
<xs:element ref='mac' minOccurs='1' maxOccurs='1'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='keyreq'>
<xs:complexType>
<xs:attribute name='id' type='xs:string' use='required'/>
<xs:sequence>
<xs:element ref='pkey' minOccurs='0' maxOccurs='1'/>
<xs:element ref='header' minOccurs='0' maxOccurs='1'/>
<xs:element ref='cmk' minOccurs='1' maxOccurs='1'/>
<xs:element ref='iv' minOccurs=1' maxOccurs='1'/>
<xs:element ref='data' minOccurs='1' maxOccurs='1'/>
<xs:element ref='mac' minOccurs='1' maxOccurs='1'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='cmk'>
<xs:complexType>
<xs:simpleType>
<xs:extension base='xs:string'>
</xs:extension>
</xs:simpleType>
</xs:complexType>
</xs:element>
<xs:element name='iv'>
<xs:complexType>
<xs:simpleType>
<xs:extension base='xs:string'>
</xs:extension>
</xs:simpleType>
</xs:complexType>
</xs:element>
<xs:element name='data'>
<xs:complexType>
<xs:simpleType>
<xs:extension base='xs:string'>
</xs:extension>
</xs:simpleType>
</xs:complexType>
</xs:element>
<xs:element name='header'>
<xs:complexType>
<xs:simpleType>
<xs:extension base='xs:string'>
</xs:extension>
</xs:simpleType>
</xs:complexType>
</xs:element>
<xs:element name='mac'>
<xs:complexType>
<xs:simpleType>
<xs:extension base='xs:string'>
</xs:extension>
</xs:simpleType>
</xs:complexType>
</xs:element>
<xs:element name='pkey'>
<xs:complexType>
<xs:simpleType>
<xs:extension base='xs:string'>
</xs:extension>
</xs:simpleType>
</xs:complexType>
</xs:element>
<xs:element name='smk'>
<xs:complexType>
<xs:simpleType>
<xs:extension base='xs:string'>
</xs:extension>
</xs:simpleType>
</xs:complexType>
</xs:element>
<xs:element name='bad-timestamp' type='empty'/>
<xs:element name='decryption-failed' type='empty'/>
<xs:element name='insufficient-information' type='empty'/>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
]]></artwork>
</figure>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:30:02 |