| Network Working Group | M. Miller |
| Internet-Draft | Cisco Systems, Inc. |
| Intended status: Standards Track | February 29, 2012 |
| Expires: August 30, 2012 |
End-to-End Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)
draft-miller-xmpp-e2e-00
This document defines a method of end-to-end object encryption for the Extensible Messaging and Presence Protocol (XMPP).
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 30, 2012.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
End-to-end encryption of traffic sent over the Extensible Messaging and Presence Protocol [RFC6120] is a desirable goal. Requirements and a threat analysis for XMPP encryption are provided in [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.
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 th entity is employing. This document specifies an approach for encrypting communications between two entities which each might have multiple end-points.
This document inherits terminology defined in [RFC6120].
Security-related terms are to be understood in the sense defined in [SECTERMS].
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 [KEYWORDS].
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/>).
First, the sending agent prepares and retains the following:
For a given plaintext stanza (S), the sending agent performs the following:
NOTE: this header is intentionally lacking required attributes. The receiving agent is responsible for assembling a final, valid JWE header.
NOTE: unless otherwise indicated, all line breaks are included for readability.
The sending agent begins with the plaintext version of the <message/> stanza 'S':
<message xmlns='jabber:client'
from='juliet@capulet.lit/balcony'
to='romeo@montegue.lit/garden'
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>
and the following prerequisites:
The sending agent performs steps 1 and 2 to generate the envelope:
<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/garden'
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>
Then the sending agent performs steps 3 and 4 to generate the [JOSE-JWE] header:
{
"enc":"A256CCM",
"iv":"B7waCj2vF_sLaJfe-1GHrA==",
"adata":"1492-05-12T20:07:37.012Z",
"msize":"16"
}
Then the sending agent performs steps 5 and 6 to generate the protected content:
7LlMXd-qqPAQ_LZm6u9AR2csyDgT09z5DWdn8K5GLr_qbWRDKw2ufZrmO9YZ-jHl
1IDeXeQ9azbNNViv8gpa-prDYkXOo3QoqYOJiA0RAkPU-UjN41wqqVvV62gad_OB
Dd9q2xsNnK1PI5frIGTCZSexOIeSD3EcP0cDI_0MzMEKqpVnPbYQDkWQNrtxPs2b
lE15KcQXbHVxA9rEz7y0a-ITXruV_fOXGftkRVDuiF1yVh2xNRPa-TQxDegZh1D_
u_c2mwPLO6ED_1ZlvL7075_VL0DT01YGtDDQeyzrQWnQNEBJ4G5jFpCyqtCszbgx
9kjWjxLYNLLGxbMOtwF45OLCd8JFUIQAHoLeKp4aIWr5yp7aATX8dKvQm5_TFICt
nLonaM1e5mRPnRgg5zNeMErx6FFkqowOI1h7hVl_QHF8Ofoy99CmWKiVT3Nq5ngL
74Xm4CtiJMHnAEn2Q-10-fWuIHIEA0u4GwBaXo0ToBw4uCM4ZhG1SFSKyCKkjXmr
7TL-5jwSuuQHX6efS8Hhi7fujmqw9VXekeubsY2btl5put0SWT8_0S8ZBDMjrkXj
y7iI5NUOhQMms3ou1r01NZdzNVKcqiX5q3z1eB1FLWmGymnnj_gE_HalWUL0HoqL
93Fr1nfFLNhXLCZYhZ7By6T9NN8omp4ZYE92HMpPzgo-eCGP
Then the sending agent performs step 7 and sends the following:
<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:1'
id='835c92a8-94cd-4e96-b3f3-b2e75a438f92'>
<header>
eyJlbmMiOiJBMjU2Q0NNIiwiaXYiOiJCN3dhQ2oydkZfc0xhSmZlLTFHSHJBPT0i
LCJhZGF0YSI6IjQ5Mi0wNS0xMlQyMDowNzozNy4wMTJaIiwibXNpemUiOiIxNiJ9
</header>
<data>
7LlMXd-qqPAQ_LZm6u9AR2csyDgT09z5DWdn8K5GLr_qbWRDKw2ufZrmO9YZ-jHl
1IDeXeQ9azbNNViv8gpa-prDYkXOo3QoqYOJiA0RAkPU-UjN41wqqVvV62gad_OB
Dd9q2xsNnK1PI5frIGTCZSexOIeSD3EcP0cDI_0MzMEKqpVnPbYQDkWQNrtxPs2b
lE15KcQXbHVxA9rEz7y0a-ITXruV_fOXGftkRVDuiF1yVh2xNRPa-TQxDegZh1D_
u_c2mwPLO6ED_1ZlvL7075_VL0DT01YGtDDQeyzrQWnQNEBJ4G5jFpCyqtCszbgx
9kjWjxLYNLLGxbMOtwF45OLCd8JFUIQAHoLeKp4aIWr5yp7aATX8dKvQm5_TFICt
nLonaM1e5mRPnRgg5zNeMErx6FFkqowOI1h7hVl_QHF8Ofoy99CmWKiVT3Nq5ngL
74Xm4CtiJMHnAEn2Q-10-fWuIHIEA0u4GwBaXo0ToBw4uCM4ZhG1SFSKyCKkjXmr
7TL-5jwSuuQHX6efS8Hhi7fujmqw9VXekeubsY2btl5put0SWT8_0S8ZBDMjrkXj
y7iI5NUOhQMms3ou1r01NZdzNVKcqiX5q3z1eB1FLWmGymnnj_gE_HalWUL0HoqL
93Fr1nfFLNhXLCZYhZ7By6T9NN8omp4ZYE92HMpPzgo-eCGP
</data>
</e2e>
</message>
A receiving agent might not have the conetnt encryption key to decrypt the stanza.
Before a CEK can be requested, the receiving agent MUST have at least one public key for which it also has the private key.
To request a CEK, the receiving agent performs the following:
If the sending agent approves the request, it performs the following:
NOTE: this header is intentionally lacking required attributes. The receiving agent is responsible for assembling a final, valid JWE header.
If the sending agent does not approve of the request, it sends an <iq/> stanza of type "error" and containing the reason for denying the request:
NOTE: unless otherwise indicated, all line breaks are included for readability.
To begin a key request, the receiving agent performs step 1 from request process [keyreq-process-request] to generate the [JOSE-JWK]:
[{
"alg":"RSA",
"mod":"AL7ano5DBdNYfKChGh3xxGDtAtozO3iEm20rzbNEjSLWFjuhm46SXzeJXV8Nr6V
UXcrJ8FN85OqNv0g9GAh9VoHriNECtZJzEw3TUl8edntXOAU8IZQPIh7rrU1pqQ
anrJ9RjWZqgd42LCTpFQWMAibZAfQD2gb5NIrZUbYs4wn9Rx52ru5xkrcrIYLvP
rK8Yv3fKwuU0y0gf809Yunz_H8A5aHplzrQtFOuW8uT_tWR8Wn_2w_H6Y6bOoME
oHZGSjCQCNGzlmVrjKadp7amtMCwezXcW9iI63qIP7ObLAKEolw1XaLMEm6d-mT
_tZZwpNo_r2eKm4WhYOW2bYLfoME=",
"exp":"AQAB",
"kid":"romeo@montegue.lit/garden"
}]
Then the receiving agent performs step 2 to generate the <keyreq/>:
<keyreq xmlns='urn:ietf:params:xml:ns:xmpp-e2e:1'
id='835c92a8-94cd-4e96-b3f3-b2e75a438f92'>
<pkey>
W3siYWxnIjoiUlNBIiwibW9kIjoiQUw3YW5vNURCZE5ZZktDaEdoM3h4R0R0QXR
vek8zaUVtMjByemJORWpTTFdGanVobTQ2U1h6ZUpYVjhOcjZWVVhjcko4Rk44NU
9xTnYwZzlHQWg5Vm9IcmlORUN0Wkp6RXczVFVsOGVkbnRYT0FVOElaUVBJaDdyc
lUxcHFRYW5ySjlSaldacWdkNDJMQ1RwRlFXTUFpYlpBZlFEMmdiNU5JclpVYllz
NHduOVJ4NTJydTV4a3JjcklZTHZQcks4WXYzZkt3dVUweTBnZjgwOVl1bnpfSDh
BNWFIcGx6clF0Rk91Vzh1VF90V1I4V25fMndfSDZZNmJPb01Fb0haR1NqQ1FDTk
d6bG1WcmpLYWRwN2FtdE1Dd2V6WGNXOWlJNjNxSVA3T2JMQUtFb2x3MVhhTE1Fb
TZkLW1UX3RaWndwTm9fcjJlS200V2hZT1cyYllMZm9NRT0iLCJleHAiOiJBUUFC
Iiwia2lkIjoicm9tZW9AbW9udGVndWUubGl0L2dhcmRlbiJ9XQ==
</pkey>
</keyreq>
Then the receiving agent performs step 3 and sends the following:
<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:1'
id='835c92a8-94cd-4e96-b3f3-b2e75a438f92'>
<pkey>
W3siYWxnIjoiUlNBIiwibW9kIjoiQUw3YW5vNURCZE5ZZktDaEdoM3h4R0R0QXR
vek8zaUVtMjByemJORWpTTFdGanVobTQ2U1h6ZUpYVjhOcjZWVVhjcko4Rk44NU
9xTnYwZzlHQWg5Vm9IcmlORUN0Wkp6RXczVFVsOGVkbnRYT0FVOElaUVBJaDdyc
lUxcHFRYW5ySjlSaldacWdkNDJMQ1RwRlFXTUFpYlpBZlFEMmdiNU5JclpVYllz
NHduOVJ4NTJydTV4a3JjcklZTHZQcks4WXYzZkt3dVUweTBnZjgwOVl1bnpfSDh
BNWFIcGx6clF0Rk91Vzh1VF90V1I4V25fMndfSDZZNmJPb01Fb0haR1NqQ1FDTk
d6bG1WcmpLYWRwN2FtdE1Dd2V6WGNXOWlJNjNxSVA3T2JMQUtFb2x3MVhhTE1Fb
TZkLW1UX3RaWndwTm9fcjJlS200V2hZT1cyYllMZm9NRT0iLCJleHAiOiJBUUFC
Iiwia2lkIjoicm9tZW9AbW9udGVndWUubGl0L2dhcmRlbiJ9XQ==
</pkey>
</keyreq>
</iq>
If the sending agent accepts this key request, it performs steps 1 and 2 from accept process [keyreq-process-accept] to generate the partial [JOSE-JWE] header:
{
"alg":"RSA-OEAP",
"kid":"romeo@montegue.lit/garden"
}
Then the sending agent performs step 3 to generate the encrypted CEK:
DCKrJpLd8XYze7joNKsyvpzGD4MffVQF7apQMkPK8_vKx4J3xEqWB3tXxp6oxJF
4YHla4SFiMp44LccMEd6JchPp_23OXrBo8i7Fwo8jVH6QoQa71T_1rQj6CWQ1eF
vXiU4Qmp52F-gjuUhlKfe3qccdlFp3kLy8Mpq5mDdq6deOq0_qusqr8QTqrT5LN
IgsXYzrdiDdKx8KSKpI4FBB_H1x-A1C97DfJk9s5H7GzKVm2BRWVXWjJfO4lckE
Z45ZJkA3CKq86Yth3YBetoScPVLhoRoO2qqBg4gR9dDO5mXnOgPslVfXWvegexH
AyhHmJZsj3yV_pW1Rlb5jn5J4Rw==
Then the sending agent performs step 4 to generate the <keyreq/> response:
<keyreq xmlns='urn:ietf:params:xml:ns:xmpp-e2e:1'
id='835c92a8-94cd-4e96-b3f3-b2e75a438f92'>
<header>
eyJhbGciOiJSU0EtT0VBUCIsImtpZCI6InJvbWVvQG1vbnRlZ3VlLmxpc3QvZ2F
yZGVuIn0=
</header>
<cek>
DCKrJpLd8XYze7joNKsyvpzGD4MffVQF7apQMkPK8_vKx4J3xEqWB3tXxp6oxJF
4YHla4SFiMp44LccMEd6JchPp_23OXrBo8i7Fwo8jVH6QoQa71T_1rQj6CWQ1eF
vXiU4Qmp52F-gjuUhlKfe3qccdlFp3kLy8Mpq5mDdq6deOq0_qusqr8QTqrT5LN
IgsXYzrdiDdKx8KSKpI4FBB_H1x-A1C97DfJk9s5H7GzKVm2BRWVXWjJfO4lckE
Z45ZJkA3CKq86Yth3YBetoScPVLhoRoO2qqBg4gR9dDO5mXnOgPslVfXWvegexH
AyhHmJZsj3yV_pW1Rlb5jn5J4Rw==
</cek>
</keyreq>
Then the sending agent performs step 5 and sends the following:
<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:1'
id='835c92a8-94cd-4e96-b3f3-b2e75a438f92'>
<header>
eyJhbGciOiJSU0EtT0VBUCIsImtpZCI6InJvbWVvQG1vbnRlZ3VlLmxpc3QvZ2F
yZGVuIn0=
</header>
<cek>
DCKrJpLd8XYze7joNKsyvpzGD4MffVQF7apQMkPK8_vKx4J3xEqWB3tXxp6oxJF
4YHla4SFiMp44LccMEd6JchPp_23OXrBo8i7Fwo8jVH6QoQa71T_1rQj6CWQ1eF
vXiU4Qmp52F-gjuUhlKfe3qccdlFp3kLy8Mpq5mDdq6deOq0_qusqr8QTqrT5LN
IgsXYzrdiDdKx8KSKpI4FBB_H1x-A1C97DfJk9s5H7GzKVm2BRWVXWjJfO4lckE
Z45ZJkA3CKq86Yth3YBetoScPVLhoRoO2qqBg4gR9dDO5mXnOgPslVfXWvegexH
AyhHmJZsj3yV_pW1Rlb5jn5J4Rw==
</cek>
</keyreq>
</iq>
Several scenarios are possible when an entity receives an encrypted stanza:
In the case where 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 [RFC6120].
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 [RFC6121].
In the case where the protocol is understood but the receiving agent does not have enough information to decrypt the payload, it SHOULD request the additional information as described in Section 4.
If the key request fails, 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 [RFC6120]), optionally supplemented by an application-specific error condition element of <insufficient-information/>:
<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:1'
id='835c92a8-94cd-4e96-b3f3-b2e75a438f92'>
<header>[XML character data]</header>
<data>[XML character data]</header>
</e2e>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<insufficient-information xmlns='urn:ietf:params:xml:ns:xmpp-e2e'/>
</error>
</message>
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).
In the case where the protocol is understood but the receiving agent is unable to decrypt the payload, the receiving agent SHOULD return a <bad-request/> error to the sending agent (as described in [RFC6120]), optionally supplemented by an application-specific error condition element of <decryption-failed/> (previously defined in [RFC3923]):
<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:1'
id='835c92a8-94cd-4e96-b3f3-b2e75a438f92'>
<header>[XML character data]</header>
<data>[XML character data]</header>
</e2e>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<decryption-failed xmlns='urn:ietf:params:xml:ns:xmpp-e2e'/>
</error>
</message>
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).
In Case #4, the receiving agent MAY return a <not-acceptable/> error to the sender (as described in [RFC6120]), optionally supplemented by an application-specific error condition element of <bad-timestamp/> (previously defined in [RFC3923]):
<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:1'
id='835c92a8-94cd-4e96-b3f3-b2e75a438f92'>
<header>[XML character data]</header>
<data>[XML character data]</header>
</e2e>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<bad-timestamp xmlns='urn:ietf:params:xml:ns:xmpp-e2e'/>
</error>
</message>
In the case where the protocol is understood and the receiving agent successfully decrypted the payload, it MUST NOT return a stanza error.
If the payload is an <iq/> of type "get" or "set", and the response is an error, the receiving agent MUST send the encrypted response in an <iq/> of type "result", to prevent exposing information about the payload.
Timestamps are included to help prevent replay attacks. All timestamps MUST conform to [DATETIME] 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:
The foregoing timestamp checks assume that the recipient is online when the message is received. However, if the recipient is offline then the server will probably 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 [OFFLINE], when sending an offline message to the recipient, the server SHOULD include delayed delivery data as specified in [DELAY] 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.
The following limitations and caveats apply:
All algorithms that MUST be implemented for [JOSE-JWE] also MUST be implemented for this specification.
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.
A sender SHOULD NOT use the same CEK for stanzas intended for different recipients.
A sender MAY re-use a CEK for several stanzas to the same recpient. In this case, the CID remains the same, but MUST generate a new IV (and other data) for each encrypted stanza. The sender SHOULD periodically generate a new CEK; however, this specification does not mandate any specific algorithms or processes.
A URN sub-namespace of encrypted content for the Extensible Messaging and Presence Protocol (XMPP) is defined as follows.
| [OFFLINE] | Saint-Andre, P., "Best Practices for Handling Offline Messages", XSF XEP 0160, January 2006. |
| [RFC3923] | Saint-Andre, P., "End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)", RFC 3923, October 2004. |
| [RFC4086] | Eastlake, D., Schiller, J. and S. Crocker, "Randomness Requirements for Security", RFC 4086, June 2005. |
| [RFC6120] | Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6121, March 2011. |
| [RFC6121] | Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 6121, March 2011. |
The following XML schema is descriptive, not normative.
<?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:1'
xmlns='urn:ietf:params:xml:ns:xmpp-e2e:1'
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='data' 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='header' minOccurs='0' maxOccurs='1'/>
<xs:element ref='pkey' minOccurs='0' maxOccurs='1'/>
<xs:element ref='cek' minOccurs='0' maxOccurs='1'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='cek'>
<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='pkey'>
<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>