moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

0.10 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3718 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2009-12-15 18:01:29 +00:00
parent 8b9b008509
commit 22558bda91
1 changed files with 235 additions and 586 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

821
xep-0189.xml
View File

@ -21,9 +21,15 @@
<supersedes>None</supersedes>
<supersededby>None</supersededby>
<shortname>NOT_YET_ASSIGNED</shortname>
&ianpaterson;
&stpeter;
&dmeyer;
&ianpaterson;
<revision>
<version>0.10</version>
<date>2009-12-15</date>
<initials>psa</initials>
<remark><p>Major revision; split into three namespaces and three corresponding PEP nodes, one each for public keys, attestations, and revocations; iterated the version number for public keys to urn:xmpp:pubkey:1; added detailed data to each node payload; removed some use cases to simply the protocol.</p></remark>
</revision>
<revision>
<version>0.9</version>
<date>2009-03-08</date>
@ -79,518 +85,251 @@
<remark><p>Initial version.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>This document defines different methods an entity MAY use for publishing its long-term public keys:</p>
<p>End-to-end encryption between XMPP clients and mutual authentication between a client and a server are desirable goals for the XMPP network. To enable these features, typically an XMPP user will need to possess a public key (or multiple keys), along with an associated private key that is not made public. The goal of this document is to provide simple methods for the exchange of public keys among XMPP users -- specifically, data formats that enable an XMPP entity to complete the following use cases:</p>
<ul>
<li>Publishing public keys to a set of subscribers.</li>
<li>Querying another entity for its public keys.</li>
<li>Sign one key with another</li>
<li>Publish its current public keys.</li>
<li>Revoke keys that are no longer in use.</li>
<li>Publish signed copies of its public keys (called attestations).</li>
<li>Discover and retrieve public keys published by other entities.</li>
</ul>
<p>An entity MAY have multiple public keys with different formats, signatures, algorithms, strengths and expiry dates. Each client used by a user MAY use different keys. Guidelines how to manage different public keys in included in this document.</p>
</section1>
<section1 topic='The KeyInfo Format' anchor='keyinfo'>
<p>This document does not use the 'http://www.w3.org/2000/09/xmldsig#' namespace as specified in &w3xmlsig; because it is too complicated and the complexity is not needed for this use case. The &lt;keyinfo/&gt; element defined in the 'urn:xmpp:pubkey:0' namespace &VNOTE; is based on the ASCII output most cryptographic libraries support. It has two parts: the public key data and signatures from other keys (optional). The optional argument 'jid' SHOULD be set if the X.509 certificate or OpenPGP key does not belong to the user providing it to another.</p>
<section2 topic='X.509 Certificate' anchor='x509'>
<p>The public key data is the X.509 certificate in DER encoding. To be included in an XML stream the data is Base64 encoded.</p>
<example caption='X.509 Certificate'><![CDATA[
<keyinfo xmlns='urn:xmpp:pubkey:0'>
<x509cert>
MIICCTCCAXKgAwIBAgIJALhU0Id6xxwQMA0GCSqGSIb3DQEBBQUAMA4xDDAKBgNV
BAMTA2ZvbzAeFw0wNzEyMjgyMDA1MTRaFw0wODEyMjcyMDA1MTRaMA4xDDAKBgNV
BAMTA2ZvbzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0DPcfeJzKWLGE22p
RMINLKr+CxqozF14DqkXkLUwGzTqYRi49yK6aebZ9ssFspTTjqa2uNpw1U32748t
qU6bpACWHbcC+eZ/hm5KymXBhL3Vjfb/dW0xrtxjI9JRFgrgWAyxndlNZUpN2s3D
hKDfVgpPSx/Zp8d/ubbARxqZZZkCAwEAAaNvMG0wHQYDVR0OBBYEFJWwFqmSRGcx
YXmQfdF+XBWkeML4MD4GA1UdIwQ3MDWAFJWwFqmSRGcxYXmQfdF+XBWkeML4oRKk
EDAOMQwwCgYDVQQDEwNmb2+CCQC4VNCHesccEDAMBgNVHRMEBTADAQH/MA0GCSqG
SIb3DQEBBQUAA4GBAIhlUeGZ0d0msNVxYWAXg2lRsJt9INHJQTCJMmoUeTtaRjyp
ffJtuopguNNBDn+MjrEp2/+zLNMahDYLXaTVmBf6zvY0hzB9Ih0kNTh23Fb5j+yK
QChPXQUo0EGCaODWhfhKRNdseUozfNWOz9iTgMGw8eYNLllQRL//iAOfOr/8
</x509cert>
</keyinfo>
]]></example>
</section2>
<section2 topic='OpenPGP' anchor='openpgp'>
<p>The public key data is the OpenPGP public key (&rfc4880;) using binary output. Like X.509 certificates the data MUST be Base64 encoded to fit in an XML stream.</p>
<example caption='OpenPGP Public Key'><![CDATA[
<keyinfo xmlns='urn:xmpp:pubkey:0'
jid='romeo@montague.net'>
<pgpdata>
mQGiBDsKPy8RBACG1vVC8+5jMbtr8YUSfL2ciIu/Zb7/dDhwFd4iFlH7BIEt3RjR
wmiCUw/pcL8LHav7L2L4/Yxm8peJxyK0c11tP5Mq8kG3v55BSkZzn3fwKilEYG1c
rkOPWMEHds3c8kLDn+WNyxrSpw10EyJSsXc0edBdl7eLHiNQsCNmPpZhvwCg8uCQ
...
HDU4Qg9lslDyfa2pHqkweHvC/LmIxrZeCSxOgSMLV8bqbbra1n3F4vdqgc8VP8I2
o9wBSf3HMohGBBgRAgAGBQI7Cj82AAoJEE598tACtM5EuWIAn0tHJF+Bk7pPAngp
hFOdFgS8UBSAAJ9ZPviS2XDzrWRpiyKV+hDqO/WTHA==
</pgpdata>
</keyinfo>
]]></example>
</section2>
<section2 topic='Signatures' anchor='signature'>
<p>Besides the data, a key can have one or more signatures. A signature can be used to sign an X.509 certificate with an OpenPGP key or the other way around. This makes it possible to verify a self-signed X.509 certificate with the OpenPGP web-of-trust. A second use case is the concept of user and client keys. A user MAY choose to use a different X.509 certificates for each client for &xtls; or &saslext;. All these client key can be signed by a user key. Once the user key is known, all clients can be verified. This XMPP based approach makes it possible to use self-signed certificates without setting up a CA (see <link url='#management'>Key Management Guidelines for Secure End-to-End Communication</link>).</p>
<p>The signature has an issuer and the signature data. The issuer contains the fingerprint of the key that was used to create the signature. An optional argument 'jid' SHOULD be set if the issuer has a different base JID than the key to sign. This makes it possible to find the issuer key using PEP (see <link url='#pub'>Public Key Publication via PEP</link>).</p>
<p>While OpenPGP defines how to sign a string, X.509 does not specify the hash algorithm. For X.509 the signature data MUST contain an attribute what hash and sign algorithms were used. This document only defines 'RSA-SHA1' at this time. To make it easier to use standard cryptographic libraries the hash MUST contain the ASN.1 BER SHA1 algorithm designator prefix required in PKCS1. See XML-SIG section 6.4.2 how to hash and sign a string using RSA-SHA1. In most cases the cryptographic library will automatically take care of this. The data to sign is the X.509 certificate in DER encoding or the OpenPGP binary string of the fingerprint (the provided key data without Base64 encoding).</p>
<p>The next example contains an X.509 certificate signed by the key defined in the first example.</p>
<example caption='X.509 Certificate with external Signature'><![CDATA[
<keyinfo xmlns='urn:xmpp:pubkey:0'>
<x509cert>
MIICXDCCAcWgAwIBAgIJAKBfLqul2lj3MA0GCSqGSIb3DQEBBQUAMCkxJzAlBgNV
BAMUHmRtZXllckBqYWJiZXIuY29tXDJmdGVzdGNsaWVudDAeFw0wODA5MDYxOTI0
MjVaFw0wOTA5MDYxOTI0MjVaMCkxJzAlBgNVBAMUHmRtZXllckBqYWJiZXIuY29t
XDJmdGVzdGNsaWVudDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwaRLyj7J
/mmliYhjEwGnRGRs6gmcPaIywEK2QLFz6c3/RmRabYbIOE0iZ22D33TguSNQBWfd
lweT3bBETUhd3yuCcqWO5Ptiq/6wulMlxVeV5mxwNP/IF94VPWj0jHbRJcU8ZhS4
UnX6R5q6OSfBGdUU4mYKdiaHpgqTAO9eeqUCAwEAAaOBizCBiDAdBgNVHQ4EFgQU
b8touIdFuXF5clv2I/S1aOOFdN4wWQYDVR0jBFIwUIAUb8touIdFuXF5clv2I/S1
aOOFdN6hLaQrMCkxJzAlBgNVBAMUHmRtZXllckBqYWJiZXIuY29tXDJmdGVzdGNs
aWVudIIJAKBfLqul2lj3MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEA
pA5tI1J9Qpn3jSoQctFksRLb2H3A48R3rU8/qnarwE/AyOvth3k3ulLEmhJBT+0S
mVb6WzrZEA/2plu7DhR8ylhuvJv6cAEIN+TPha3yzO2P8uoVZf7hdunOhMLl2Z6w
xEfiGI5X9OsaMeFOQa+B2C3uUVAMLbVV7Rp/qQkai1Y=
</x509cert>
<section1 topic='Approach' anchor='approach'>
<p>This document assumes that each user will have a privately-generated key. A user <strong>might</strong> have more than one key (e.g., different keys for different clients) and the user's key <strong>might</strong> be signed by other entities, such as a certification authority (CA) or another user. However, the simplest case is a single key per user.</p>
<p>The data formats defined here are deliberately kept very simple, with the key itself represented as ASCII output (of the kind supported by most cryptographic libraries) and any metadata represented using a few straightforward XML elements and attributes. This document does not use the 'http://www.w3.org/2000/09/xmldsig#' namespace as specified in &w3xmlsig;; although that format is quite powerful, it introduces unnecessary levels of complexity for this use case.</p>
<p>We define three payload elements:</p>
<ol>
<li>The &lt;pubkey/&gt; element (qualified by the 'urn:xmpp:pubkey:1' namespace) specifies a single public key for a user.</li>
<li>The &lt;revoke/&gt; element (qualified by the 'urn:xmpp:revoke:1' namespace) specifies old keys that a user once used but has now revoked.</li>
<li>The &lt;attest/&gt; element (qualified by the 'urn:xmpp:attest:1' namespace) specifies one or more signed copies of a user's public key.</li>
</ol>
<p>An entity MAY support only public key publishing (the 'urn:xmpp:pubkey:1' namespace) and not support revocations and attestations.</p>
</section1>
<section1 topic='Public Keys' anchor='keys'>
<p>A single public key is contained in a &lt;pubkey/&gt; element qualified by the 'urn:xmpp:pubkey:1' namespace &VNOTE;, for which the defined child elements are as follows:</p>
<table caption='Children of the &lt;pubkey/&gt; Element'>
<tr>
<th>Element</th>
<th>Description</th>
</tr>
<tr>
<td>&lt;begin/&gt;</td>
<td>The UTC DateTime before which the key shall not be considered valid, formatted according to &xep0082;.</td>
</tr>
<tr>
<td>&lt;end/&gt;</td>
<td>The UTC DateTime after which the key shall not be considered valid, formatted according to <cite>XEP-0082</cite>.</td>
</tr>
<tr>
<td>&lt;jid/&gt;</td>
<td>The XMPP address associated with this key.</td>
</tr>
<tr>
<td>&lt;key/&gt;</td>
<td>The ASCII output representation of an RSA public key generated in accordance with &rfc3447;.</td>
</tr>
<tr>
<td>&lt;print/&gt;</td>
<td>The SHA-256 fingerprint for this key.</td>
</tr>
<tr>
<td>&lt;uri/&gt;</td>
<td>A URI at which the key can be retrieved outside the XMPP network; this element is OPTIONAL.</td>
</tr>
</table>
<p>An example follows.</p>
<example caption='A public key'><![CDATA[
<pubkey xmlns='urn:xmpp:pubkey:1'>
<begin>2009-12-11T20:12:37</begin>
<end>2010-12-11T23:59:59</end>
<jid>peter@jabber.org</jid>
<key>
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA25/Y7oonF3+pRjZCk0cQ
lQFiUFvyMeUOnn01NLfqfBeT4xjahsxaYFPd+V8jIHtpO3nbkpfrBh5aLPCkqDzS
UFvmLaVSIMUt085kcT/Yv72BUWUGaISt7swSNfictRbVZ0k8TbXUDLIAYWN8lsie
NVxL13PS9pu3WNoORuKAV5RuzDS3djnjb6fti7fTwEUpQVwRrJXY6jNhv4c4zE3x
Pjm48gIlHbZrxuWNrXnKT6uwXnr6PJ6O3YspferJG1oA3kmOwm41yWDkalbKgkNZ
WeS+ahB/i9LIG+41CdekPpI0Kr0Ll9X7+zaPV6xzjlG8dYy7ZGm4eTL9STuWlPdL
+wIDAQAB
</key>
<print>13475c8e27399908b4447d7c52ab30822872832eba3a654f0d80e07fb4157673</print>
</pubkey>
]]></example>
</section1>
<section1 topic='Revocations' anchor='revocations'>
<p>A user can revoke his own key. The revocation is contained in a &lt;revoke/&gt; element qualified by the 'urn:xmpp:revoke:1' namespace &VNOTE;, for which the defined child elements are as follows:</p>
<table caption='Children of the &lt;revoke/&gt; Element'>
<tr>
<th>Element</th>
<th>Description</th>
</tr>
<tr>
<td>&lt;key/&gt;</td>
<td>The public key that was revoked.</td>
</tr>
<tr>
<td>&lt;keyprint/&gt;</td>
<td>The SHA-256 fingerprint of the public key that was revoked.</td>
</tr>
<tr>
<td>&lt;signature/&gt;</td>
<td>A signature for the revocation, as described below.</td>
</tr>
<tr>
<td>&lt;revocationprint/&gt;</td>
<td>The SHA-256 fingerprint of the key used to sign the revocation.</td>
</tr>
<tr>
<td>&lt;revocationtime/&gt;</td>
<td>The UTC DateTime at which the key was revoked, formatted according to <cite>XEP-0082</cite>.</td>
</tr>
</table>
<p>The data that is signed MUST be the revoked public key (i.e., the XML character data of the &lt;key/&gt; element), the SHA-256 fingerprint of the revoked public key (i.e., the XML character data of the &lt;keyprint/&gt; element), the SHA-256 fingerprint of the key used to sign the revocation (i.e., the XML character data of the &lt;revocationprint/&gt; element), and the time of the revocation (i.e., the XML character data of the &lt;revocationtime/&gt; element), concatenated together with no spaces or other additional characters.</p>
<p>As an example, consider a revocation of the key from Example 1, where the SHA-256 fingerprint of the revoked key is 13475c8e27399908b4447d7c52ab30822872832eba3a654f0d80e07fb4157673, the SHA-256 fingerprint of the key used to sign the revocation is becb78566783166f4a1a7c64e28dae288fe1a0f2825f6b593b336ce186c6b056, and the time of the revocation is 2009-12-14T20:49:16Z. The string to be signed would be as follows (where line breaks are not significant).</p>
<code>
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA25/Y7oonF3+pRjZCk0cQ
lQFiUFvyMeUOnn01NLfqfBeT4xjahsxaYFPd+V8jIHtpO3nbkpfrBh5aLPCkqDzS
UFvmLaVSIMUt085kcT/Yv72BUWUGaISt7swSNfictRbVZ0k8TbXUDLIAYWN8lsie
NVxL13PS9pu3WNoORuKAV5RuzDS3djnjb6fti7fTwEUpQVwRrJXY6jNhv4c4zE3x
Pjm48gIlHbZrxuWNrXnKT6uwXnr6PJ6O3YspferJG1oA3kmOwm41yWDkalbKgkNZ
WeS+ahB/i9LIG+41CdekPpI0Kr0Ll9X7+zaPV6xzjlG8dYy7ZGm4eTL9STuWlPdL
+wIDAQAB13475c8e27399908b4447d7c52ab30822872832eba3a654f0d80e07f
b4157673becb78566783166f4a1a7c64e28dae288fe1a0f2825f6b593b336ce1
86c6b0562009-12-14T20:49:16Z
</code>
<p>An example follows.</p>
<example caption='A revocation'><![CDATA[
<revocation xmlns='urn:xmpp:revoke:1'>
<key>
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA25/Y7oonF3+pRjZCk0cQ
lQFiUFvyMeUOnn01NLfqfBeT4xjahsxaYFPd+V8jIHtpO3nbkpfrBh5aLPCkqDzS
UFvmLaVSIMUt085kcT/Yv72BUWUGaISt7swSNfictRbVZ0k8TbXUDLIAYWN8lsie
NVxL13PS9pu3WNoORuKAV5RuzDS3djnjb6fti7fTwEUpQVwRrJXY6jNhv4c4zE3x
Pjm48gIlHbZrxuWNrXnKT6uwXnr6PJ6O3YspferJG1oA3kmOwm41yWDkalbKgkNZ
WeS+ahB/i9LIG+41CdekPpI0Kr0Ll9X7+zaPV6xzjlG8dYy7ZGm4eTL9STuWlPdL
+wIDAQAB
</key>
<keyprint>60561AEE-4187-4122-8A71-ACF9195DE572</keyprint>
<revocationprint>becb78566783166f4a1a7c64e28dae288fe1a0f2825f6b593b336ce186c6b056</revocationprint>
<revocationtime>2009-12-14T20:49:16Z</revocationtime>
<signature>
<issuer algo='sha1'>428b1358a286430f628da23fb33ddaf6e474f5c5</issuer>
<value method='RSA-SHA1'>
E3q/UkjRR3zcZMcIIoE2sSVKUATl26zyzO1Pmoe96p8apW91c3a0KqkQp1ZMBqXX
+e2ImqQ79CKv+9qzXitxx+V4EcniKN0ZsSR+9ZbfflxkOvmBa2rpq9hFE1NYyfuT
fsAZkRhAGlP7P5ELcvhqJ4WL6qBPYQU2NEnbVlcZSbA=
</value>
iEYEARECAAYFAksnvfsACgkQNL8k5A2w/vyVHgCglI5fPQfcu1e5PTA3bMPKiL0F
J5cAnirpKzJ45OD+03b66UHoIosKQ31O
=PGFT
</signature>
</keyinfo>
]]></example>
</section2>
</section1>
<section1 topic='Public Key Publication via PEP' anchor='pub'>
<p>An entity SHOULD follow the best practices defined in &xep0222; to publish its long-term public keys via its own server. Processes for doing so are described in the following sections.</p>
<section2 topic='Creating the Node' anchor='pub-create'>
<p>If the pubkeys PEP node does not exist already then the entity needs to create it. The node MUST have a NodeID of "urn:xmpp:pubkey:0" &VNOTE;.</p>
<p>The node MUST be configured as follows:</p>
<ul>
<li>Items published to the node are persistent (this is done by setting the "persist_items" option to true).</li>
<li>Keys will be pushed to subscribers only when new keys are published, not when subscribers become newly available or when a new subscription is created (this is done by setting the "send_last_published_item" option to "never").</li>
</ul>
<p>If the user wants to control access to his/her identity (see <link url='#security'>Security Considerations</link>) then the node access model SHOULD be something other than "open" (this can be done by setting the "access_model" option to a value of "authorize", "presence", "roster", or "whitelist").</p>
<example caption='Entity Creates Node'><![CDATA[
<iq from='juliet@capulet.com/balcony'
id='hfgt54ew'
type='set'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<create node='urn:xmpp:pubkey:0'/>
<configure>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#node_config</value>
</field>
<field var='pubsub#persist_items'>
<value>1</value>
</field>
<field var='pubsub#send_last_published_item'>
<value>never</value>
</field>
<field var='pubsub#access_model'>
<value>roster</value>
</field>
<field var='pubsub#roster_groups_allowed'>
<value>friends</value>
</field>
</x>
</configure>
</pubsub>
</iq>
]]></example>
<p>Alternatively, if the entity's pubsub service supports both the "auto-create" and "publish-options" features, then the entity MAY create the node by publishing a key and in the first publish including a &lt;publish-options/&gt; element. However, note that not all pubsub services support this feature, since it is optional in &xep0060;.</p>
<example caption='Entity Auto-Creates Node and Publishes an RSA Key'><![CDATA[
<iq from='juliet@capulet.com/balcony'
id='hfgt54ed'
type='set'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:pubkey:0'>
<item id='Juliet-PGP-Key-Hash'>
<keyinfo xmlns='urn:xmpp:pubkey:0'>
<openpgp>PKP-Key-Base64-encoded</openpgp>
</keyinfo>
</item>
</publish>
<configure>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#node_config</value>
</field>
<field var='pubsub#persist_items'>
<value>1</value>
</field>
<field var='pubsub#send_last_published_item'>
<value>never</value>
</field>
<field var='pubsub#access_model'>
<value>roster</value>
</field>
<field var='pubsub#roster_groups_allowed'>
<value>friends</value>
</field>
</x>
</configure>
</pubsub>
</iq>
]]></example>
</section2>
<section2 topic='Publishing a Key' anchor='pub-publish'>
<p>The entity publishes a key by sending a pubsub publish request to the pubsub service. A previously published key can be updated by re-publishing the key using the same ItemID. The value of the ItemID SHOULD be the fingerprint of the X.509 certificate or the OpenPGP key and SHOULD be written in lower case. Since X.509 has no standard fingerprint mechanisms, the SHA1 value in hex is SHOULD be used as ItemID. Therefore subscribers or other interested entities are able to request a single key by specifying its fingerprint (for example, when a subscriber is using <cite>XTLS</cite>).</p>
<example caption='Entity Publishes an X.509 Certificate to its Server'><![CDATA[
<iq from='juliet@capulet.com/balcony'
id='gfy54e66'
type='set'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:pubkey:0'>
<item id='Juliet-X509-Cert-Hash'>
<keyinfo xmlns='urn:xmpp:pubkey:0'>
<x509cert>
Certificate-in-DER-format-Base64-encoded
</x509cert>
<signature>
<issuer>Juliet-PGP-Key-Hash</issuer>
<value>
Signature-Base64-encoded
</value>
</signature>
</keyinfo>
</item>
</publish>
</pubsub>
</iq>
]]></example>
<p>After the account owner publishes the key, the pubsub service shall send a notification to each subscriber or otherwise authorized and interested entity.</p>
<example caption='Pubsub Service Sends Notification with Key'><![CDATA[
<message to='romeo@montague.net/garden' from='juliet@capulet.com' type='headline'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='urn:xmpp:pubkey:0'>
<item id='Juliet-X509-Cert-Hash'>
<keyinfo xmlns='urn:xmpp:pubkey:0'>
<x509cert>
Certificate-in-DER-format-Base64-encoded
</x509cert>
<signature>
<issuer>Juliet-PGP-Key-Hash</issuer>
<value>
Signature-Base64-encoded
</value>
</signature>
</keyinfo>
</item>
</items>
</event>
<addresses xmlns='http://jabber.org/protocol/address'>
<address type='replyto' jid='juliet@capulet.com/balcony'/>
</addresses>
</message>
]]></example>
<p>Note: The stanza containing the event notification (see example above) MAY also include 'replyto' data (as specified by the &xep0033; protocol) to provide an explicit association between the published data and the <em>resource</em> that published it.</p>
</section2>
</section1>
<section1 topic='Public Key Retrieval via PEP' anchor='retrieve'>
<example caption='Subscriber Requests Keys from Account'><![CDATA[
<iq from='romeo@montague.net/garden'
to='juliet@capulet.com'
id='hfgtredy'
type='get'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:pubkey:0'/>
</pubsub>
</iq>
]]></example>
<example caption='Entity&apos;s Server Returns Keys to Subscriber'><![CDATA[
<iq from='juliet@capulet.com'
to='romeo@montague.net/garden'
id='hfgtredy'
type='result'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:pubkey:0'>
<item id='Juliet-PGP-Key-Hash'>
<keyinfo xmlns='urn:xmpp:pubkey:0'>
<pgpdata>
PKP-Key-Base64-encoded
</pgpdata>
</keyinfo>
</item>
<item id='Juliet-X509-Cert-Hash'>
<keyinfo xmlns='urn:xmpp:pubkey:0'>
<x509cert>
Certificate-in-DER-format-Base64-encoded
</x509cert>
</keyinfo>
</item>
</items>
</pubsub>
</iq>
]]></example>
<example caption='Subscriber Requests Specific Key'><![CDATA[
<iq from='romeo@montague.net/garden'
to='juliet@capulet.com'
id='gf654ewq'
type='get'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:pubkey:0'>
<item id='Juliet-X509-Cert-Hash'/>
</items>
</pubsub>
</iq>
]]></example>
<example caption='Entity&apos;s Server Returns Key to Subscriber'><![CDATA[
<iq from='juliet@capulet.com'
to='romeo@montague.net/garden'
id='gf654ewq'
type='result'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:pubkey:0'>
<item id='Juliet-X509-Cert-Hash'>
<keyinfo xmlns='urn:xmpp:pubkey:0'>
<x509cert>
Certificate-in-DER-format-Base64-encoded
</x509cert>
</keyinfo>
</item>
</items>
</pubsub>
</iq>
</revocation>
]]></example>
</section1>
<section1 topic='Requesting Public Keys Directly From Another Entity' anchor='request'>
<p>If an entity wishes to request the public keys of another entity and it cannot access the keys via <cite>Personal Eventing via Pubsub</cite>, then the entity MAY send an &IQ; of type 'get' to the other entity, containing an empty &lt;pubkeys/&gt; element qualified by the 'urn:xmpp:pubkey:0' namespace &VNOTE;.</p>
<example caption='Public keys request'><![CDATA[
<iq from='romeo@montague.net/garden'
to='juliet@capulet.com/balcony'
<section1 topic='Attestations' anchor='attestations'>
<p>Whether in the context of the public key infrastructure (PKI) or a web of trust, a user might want to publish signed copies of his public key, where the signer might be another user or a trusted third party such as a certification authority (CA). The signing key could even be another key owned by the user (e.g., a primary key used to sign a secondary key associated with a particular device controlled by the user). Furthermore, the signing material might be an RSA key, a DSA key, an X.509 certificate, an OpenPGP key, or any other format.</p>
<p>Each signed copy is contained in an &lt;attest/&gt; element qualified by the 'urn:xmpp:attest:1' namespace &VNOTE;, for which the defined child elements are as follows:</p>
<table caption='Children of the &lt;attest/&gt; Element'>
<tr>
<th>Element</th>
<th>Description</th>
</tr>
<tr>
<td>&lt;keyprint/&gt;</td>
<td>The SHA-256 fingerprint of the public key that was signed.</td>
</tr>
<tr>
<td>&lt;signature/&gt;</td>
<td>The signature itself, as described below.</td>
</tr>
<tr>
<td>&lt;signerjid/&gt;</td>
<td>The XMPP address of the signer.</td>
</tr>
<tr>
<td>&lt;signerprint/&gt;</td>
<td>The SHA-256 fingerprint of the signer's key.</td>
</tr>
<tr>
<td>&lt;signtime/&gt;</td>
<td>The UTC DateTime at which the key was signed, formatted according to <cite>XEP-0082</cite>.</td>
</tr>
</table>
<p>The data that is signed MUST be the user's public key (i.e., the XML character data of the &lt;key/&gt; element), the SHA-256 fingerprint of the user's public key (i.e., the XML character data of the &lt;keyprint/&gt; element), the signer's JID (i.e., the XML character data of the &lt;signerjid/&gt; element), the SHA-256 fingerprint of the signer's key (i.e., the XML character data of the &lt;signerprint/&gt; element), and the time of the attestation (i.e., the XML character data of the &lt;signtime/&gt; element), concatenated together with no spaces or other additional characters.</p>
<p>As an example, consider an attestation of the key from Example 1, where the signer's JID is stpeter@jabber.org, the fingerprint of the signer's key is "becb78566783166f4a1a7c64e28dae288fe1a0f2825f6b593b336ce186c6b056", and the time of the attestation is 2009-12-14T18:43:00Z. The string to be signed would be as follows (where line breaks are not significant).</p>
<code>
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA25/Y7oonF3+pRjZCk0cQ
lQFiUFvyMeUOnn01NLfqfBeT4xjahsxaYFPd+V8jIHtpO3nbkpfrBh5aLPCkqDzS
UFvmLaVSIMUt085kcT/Yv72BUWUGaISt7swSNfictRbVZ0k8TbXUDLIAYWN8lsie
NVxL13PS9pu3WNoORuKAV5RuzDS3djnjb6fti7fTwEUpQVwRrJXY6jNhv4c4zE3x
Pjm48gIlHbZrxuWNrXnKT6uwXnr6PJ6O3YspferJG1oA3kmOwm41yWDkalbKgkNZ
WeS+ahB/i9LIG+41CdekPpI0Kr0Ll9X7+zaPV6xzjlG8dYy7ZGm4eTL9STuWlPdL
+wIDAQAB13475c8e27399908b4447d7c52ab30822872832eba3a654f0d80e07f
b4157673stpeter@jabber.orgbecb78566783166f4a1a7c64e28dae288fe1a0
f2825f6b593b336ce186c6b0562009-12-14T18:43:00Z
</code>
<example caption='RSA public key signed by OpenPGP key'><![CDATA[
<attest xmlns='urn:xmpp:attest:1'>
<keyprint>60561AEE-4187-4122-8A71-ACF9195DE572</keyprint>
<signature>
iEYEARECAAYFAksnyJ0ACgkQNL8k5A2w/vy9DgCfc1eOYZlp1P456NkjgvCtJaRX
Wi4AoIGhfzr7XMzeOzOBi9A/bxopH8O4
=MMuz
</signature>
<signerjid>stpeter@jabber.org</signerjid>
<signerprint>becb78566783166f4a1a7c64e28dae288fe1a0f2825f6b593b336ce186c6b056</signerprint>
<signtime>2009-12-14T18:43:00Z</signtime>
</attest>
]]></example>
</section1>
<section1 topic='Publication via PEP' anchor='pep'>
<p>A user SHOULD publish public keys, attestations, and revocations via &xep0163;, in particular adhering to the best practices defined in &xep0222;.</p>
<p>Any other authorized entity can then receive notifications related to the user's public keys, and retrieve keys, attestations, and revocations.</p>
<p>If the user has only one public key (the simplest and most common case), then the pubkey PEP node SHOULD have only one item, with an ItemID of "current".</p>
</section1>
<section1 topic='Requesting a Public Key Directly' anchor='request'>
<p>If it is not possible for the user to publish his key via PEP, or for a contact to retrieve the user's key via PEP, the contact MAY request the user's key directly by sending an &IQ; of type 'get' to the user's particular full JID, containing an empty &lt;pubkey/&gt; element qualified by the 'urn:xmpp:pubkey:1' namespace &VNOTE;.</p>
<example caption='Public key request'><![CDATA[
<iq from='maineboy@jabber.org/bar'
to='peter@jabber.org/foo'
id='hfgt654s'
type='get'>
<pubkeys xmlns='urn:xmpp:pubkey:0'/>
<pubkey xmlns='urn:xmpp:pubkey:1'/>
</iq>
]]></example>
<p>The other entity MUST make a careful access control decision before returning only those public keys for which it holds the corresponding private key (not necessarily the full list of keys being published via <cite>Personal Eventing via Pubsub</cite>). The client MAY also include the public key which was used to sign its keys even if it does not hold the private key. In that case the &lt;keyinfo/&gt; element MUST contain the 'jid' attribute of the public key even it is belongs to the same user.</p>
<example caption='Successful public keys response'><![CDATA[
<iq from='juliet@capulet.com/balcony'
to='romeo@montague.net/garden'
<p>The receiving client then return its public key (which might be different from the overall key for the user, e.g. a key for only a particular device).</p>
<example caption='Public key response'><![CDATA[
<iq from='peter@jabber.org/foo'
to='maineboy@jabber.org/bar'
id='hfgt654s'
type='result'>
<pubkeys xmlns='urn:xmpp:pubkey:0'>
<keyinfo>
<x509cert>Juliet-X509-Client-Cert</x509cert>
<signature>
<issuer algo='sha1'>Juliet-X509-User-Cert-Hash</issuer>
<value method='RSA-SHA1'>
Signature-Base64-encoded
</value>
</signature>
</keyinfo>
<keyinfo jid='juliet@capulet.com'>
<x509cert>Juliet-X509-User-Cert</x509cert>
</keyinfo>
<keyinfo>
<pgpdata>Juliet-PGP-Key</pgpdata>
</keyinfo>
</pubkeys>
<pubkey xmlns='urn:xmpp:pubkey:1'>
<begin>2009-12-11T20:12:37</begin>
<end>2010-12-11T23:59:59</end>
<jid>peter@jabber.org</jid>
<key>
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA25/Y7oonF3+pRjZCk0cQ
lQFiUFvyMeUOnn01NLfqfBeT4xjahsxaYFPd+V8jIHtpO3nbkpfrBh5aLPCkqDzS
UFvmLaVSIMUt085kcT/Yv72BUWUGaISt7swSNfictRbVZ0k8TbXUDLIAYWN8lsie
NVxL13PS9pu3WNoORuKAV5RuzDS3djnjb6fti7fTwEUpQVwRrJXY6jNhv4c4zE3x
Pjm48gIlHbZrxuWNrXnKT6uwXnr6PJ6O3YspferJG1oA3kmOwm41yWDkalbKgkNZ
WeS+ahB/i9LIG+41CdekPpI0Kr0Ll9X7+zaPV6xzjlG8dYy7ZGm4eTL9STuWlPdL
+wIDAQAB
</key>
<print>13475c8e27399908b4447d7c52ab30822872832eba3a654f0d80e07fb4157673</print>
</pubkey>
</iq>
]]></example>
<p>If the receiving entity decides not to return the public keys, it MUST return an IQ error, which SHOULD be &unavailable; (to avoid divulging presence to unauthorized entities), but MAY be some other appropriate error, such as &forbidden; or &notallowed;:</p>
<example caption='Access to public keys denied'><![CDATA[
<iq from='juliet@capulet.com/balcony'
to='romeo@montague.net/garden'
id='hfgt654s'
type='error'>
<pubkeys xmlns='urn:xmpp:pubkey:0'/>
<error code='503' type='cancel'>
<service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
]]></example>
<p>An entity MAY request one or more specific public keys by specifying their fingerprints (see <link url='#pub'>Public Key Publication via PEP</link>) as the content of &lt;fingerprint/&gt; child elements:</p>
<example caption='Specific public keys request'><![CDATA[
<iq from='juliet@capulet.com/balcony'
to='romeo@montague.net/garden'
id='54fgtyre'
type='get'>
<pubkeys xmlns='urn:xmpp:pubkey:0'>
<fingerprint algo='sha1'>Juliet-X509-Cert-Hash</fingerprint>
<fingerprint>Juliet-PKP-Hash</fingerprint>
</pubkeys>
</iq>
]]></example>
<example caption='Successful specific public keys response'><![CDATA[
<iq from='juliet@capulet.com/balcony'
to='romeo@montague.net/garden'
id='54fgtyre'
type='result'>
<pubkeys xmlns='urn:xmpp:pubkey:0'>
<keyinfo>
<x509cert>
Certificate-in-DER-format-Base64-encoded
</x509cert>
</keyinfo>
<keyinfo>
<pgpdata>
PKP-Key-Base64-encoded
</pgpdata>
</keyinfo>
</pubkeys>
</iq>
]]></example>
</section1>
<section1 topic='Requesting Public Keys Directly From a Third Party' anchor='third'>
<p>An entity can request the public keys of another entity from a third party using the 'jid' attribute of the &lt;pubkeys/&gt; element to specify the JID that the keys belong to:</p>
<example caption='Requesting public keys from a third-party'><![CDATA[
<iq from='juliet@capulet.com/balcony'
to='romeo@montague.net/garden'
id='gftrse3w'
type='get'>
<pubkeys xmlns='urn:xmpp:pubkey:0' jid='benvolio@montague.net'/>
</iq>
]]></example>
<example caption='Third-party responds with public keys'><![CDATA[
<iq from='romeo@montague.net/garden'
to='juliet@capulet.com/balcony'
id='gftrse3w'
type='result'>
<pubkeys xmlns='urn:xmpp:pubkey:0' jid='benvolio@montague.net'>
<keyinfo jid='benvolio@montague.net'>
...
</keyinfo>
<keyinfo jid='benvolio@montague.net'>
...
</keyinfo>
</pubkeys>
</iq>
]]></example>
<example caption='Third party has no copies of the keys'><![CDATA[
<iq from='romeo@montague.net/garden'
to='juliet@capulet.com/balcony'
id='gftrse3w'
type='error'>
<pubkeys xmlns='urn:xmpp:pubkey:0' jid='benvolio@montague.net'/>
<error code='404' type='cancel'>
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
]]></example>
</section1>
<section1 topic='Sending Public Keys Directly To Another Entity' anchor='send'>
<p>If an entity wishes to send public keys to another entity then it MAY include them in a &MESSAGE; stanza. The entity MAY use the 'jid' attribute of the &lt;keyinfo/&gt; element to specify the JID that the keys belong to. If no 'jid' attribute is specified then the other entity SHOULD assume the keys belong to the sender of the stanza.</p>
<example caption='Sending public keys'><![CDATA[
<message from='romeo@montague.net/garden'
to='juliet@capulet.com/balcony'>
<pubkeys xmlns='urn:xmpp:pubkey:0'>
<keyinfo>
...
</keyinfo>
<keyinfo jid='benvolio@montague.net'>
...
</keyinfo>
</pubkeys>
</message>
]]></example>
</section1>
<section1 topic='Signing Public Keys' anchor='sign'>
<p>A client can add another client's X.509 certificate to the pubsub node or send it directly to another client, and the client wants that certificate signed with the user's private key. If the client is not in possession of the private key, it can send a 'sign' request to another client of the user having access to the certificate.</p>
<example caption='Client sends Signing Request'><![CDATA[
<iq from='juliet@capulet.com/chamber'
to='juliet@capulet.com/balcony'
type='set'
id='hft65du8'>
<sign node='urn:xmpp:pubkey:0'>
<issuer algo='sha1'>UserCertificateHash</issuer>
<pubkeys>
<keyinfo>
<x509cert>
Certificate-in-DER-format-Base64-encoded
<x509cert/>
</keyinfo>
<pubkeys>
</sign>
</iq>
]]></example>
<p>The signing client SHOULD only accept signing requests from clients of the same user (sharing a bare JID) and it is RECOMMENDED to use a secure end-to-end communicate according to &xtls; or &xep0250; for serverless-messing.</p>
<example caption='Signing Client Returns Keys'><![CDATA[
<iq from='juliet@capulet.com/balcony'
to='juliet@capulet.com/chamber'
type='result'
id='hft65du8'>
<pubkeys>
<keyinfo>
<x509cert>
Certificate-in-DER-format-Base64-encoded
<x509cert/>
<signature>
<issuer algo='sha1'>UserCertificateHash</issuer>
<value method='RSA-SHA1'>
Signature-Base64-encoded
</value>
</signature>
</keyinfo>
<pubkeys>
</iq>
]]></example>
<p>Possible error conditions are that the signing client does not have the requested private key, the client is not authorized to request a signature, or that the signing client requires a secure connection and the request was issued over an insecure link.</p>
<example caption='Error Conditions'><![CDATA[
<error code='404' type='cancel'>
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
<error type='auth'>
<forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
<error type='cancel'>
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<security-required xmlns='urn:xmpp:jingle:errors:0'/>
</error>
]]></example>
</section1>
<section1 topic='Key Management Guidelines for Secure End-to-End Communication' anchor='management'>
<p>Different X.509 certificates for each client, a user X.509 certificate to sign client certificates, and secure communication with friends make the scenario quite confusing. This section provides guidelines how to manage the different public keys and what kind of key to sign. The desired use case is to manage for secure end-to-end communication as defined by <cite>XTLS</cite>.</p>
<ul>
<li><p>Each client has its own certificate. This certificate is most likely self-signed.</p></li>
<li><p>The user has a user certificate and one or more clients can have access to the user's private key to sign certificates. To bootstrap the system, one client generates the certificate on behalf of the user.</p></li>
<li><p>Users SHOULD sign all their client certificates with their user certificate. To accomplish this in a userfriendly way, the user MAY log into the account with more than one client simultaneously. One client MUST have the user's private key or is trusted to issue a 'sign' request. The two clients open a secure connection between themselves based on TLS-SRP (see <cite>XTLS, Section 6</cite>). After a secure communicate between the two clients is established, the client without the user certificate requests its certificate to be signed. After that it can be uploaded to the pubsub node. The new client SHOULD also request the user certificate to be able to validate signatures for other clients.</p></li>
<li><p>If a client opens a secure connection to another user based on TLS-SRP, it SHOULD request the user certificate of its peer. It will either sign the certificate itself or ask another client with the user's private key to do so. The friend's user certificate can then be uploaded to the pubsub node of the user (not the friend). The &lt;keyinfo/&gt; element SHOULD contain the bare JID of the friend in the 'jid' attribute.</p></li>
<li><p>If a client wants to open a secure end-to-end connection to another client of the same user, it SHOULD check the pubsub node for the certificate. The certificate MUST be signed by the user's certificate.</p></li>
<li><p>If a client wants to open a secure end-to-end connection to a client of another user, it SHOULD check the its pubsub node for the friend's user certificate and the friend's pubsub node for the client certificate. The friend's user certificate MUST be signed by its own user certificate and the clients certificate MUST be signed by the friend's user certificate.</p></li>
</ul>
<p>If a user possess an OpenPGP key, the user certificate SHOULD be signed with that key. This allows another users to verify the certificate based on the OpenPGP web-of-trust, and two users might be able to bootstrap a secure communicate without the usage of TLS-SRP.</p>
</section1>
<section1 topic='Determining Support' anchor='support'>
<p>If an entity can sign certificates or OpenPGP keys with the user's private key, it MUST report that by including a service discovery feature of "urn:xmpp:pubkey:0:sign" in response to disco#info requests &VNOTE;.</p>
<example caption="Initial Service Discovery Information Request"><![CDATA[
<iq from='juliet@capulet.com/chamber'
to='juliet@capulet.com/balcony'
id='gfd68yt4'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<example caption="Service Discovery Information Response"><![CDATA[
<iq from='juliet@capulet.com/balcony'
to='juliet@capulet.com/chamber'
id='gfd68yt4'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<feature var='urn:xmpp:pubkey:0'/>
<feature var='urn:xmpp:pubkey:0:sign'/>
</query>
</iq>
]]></example>
<p>To advertise its support for public keys, revocations, and attestations, when replying to &xep0030; information requests an entity MUST return features for 'urn:xmpp:pubkey:1', 'urn:xmpp:revoke:1', and 'urn:xmpp:attest:1' respectively.</p>
<p>In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>The reliable association between a user or entity and its public keys is beyond the scope of this document. However, each client SHOULD maintain its own secure library of the public keys (or the "fingerprints" of the keys) it associates with other users (not necessarily JIDs).</p>
<p>Whenever public keys are published an identity is typically associated with a JID. Although the public keys are public information, it can be critically important for the user of the JID to keep his identity secret from all but a few specified people. Implementors MUST take great care to ensure that the identity of the user of a JID is never divulged to anyone except the entities who have been permitted by the user to access the public key.</p>
<p>The usage of secure end-to-end communication is RECOMMENDED for exchanging public keys without a pubsub service.</p>
<p>The reliable association between a user or entity and its public keys is beyond the scope of this document. However, each client SHOULD maintain its own secure library of the public keys it associates with other users.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
@ -599,110 +338,20 @@
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>This specification defines the following XML namespace:</p>
<p>This specification defines the following XML namespaces:</p>
<ul>
<li>urn:xmpp:pubkey:0</li>
<li>urn:xmpp:attest:1</li>
<li>urn:xmpp:pubkey:1</li>
<li>urn:xmpp:revoke:1</li>
</ul>
<p>Upon advancement of this specification to a status of Draft, the &REGISTRAR; shall add this namespace in the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.</p>
<p>Upon advancement of this specification to a status of Draft, the &REGISTRAR; shall add these namespaces to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.</p>
</section2>
<section2 topic='Protocol Versioning' anchor='registrar-versioning'>
&NSVER;
</section2>
<section2 topic='Service Discovery Features' anchor='registrar-features'>
<p>The XMPP Registrar shall include the following features in its registry of service discovery features (see &DISCOFEATURES;), where the string "urn:xmpp:pubkey:0" shall be replaced with the URN issued by the XMPP Registrar:</p>
<code><![CDATA[
<var>
<name>urn:xmpp:pubkey:0:sign</name>
<desc>The client is in possession of the user's private client to sign certificates.</desc>
<doc>XEP-0189</doc>
</var>
]]></code>
</section2>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:xmpp:pubkey:0'
xmlns='urn:xmpp:pubkey:0'
elementFormDefault='qualified'>
<xs:element name='pubkeys'>
<xs:complexType>
<xs:choice>
<xs:element ref='fingerprint'/>
<xs:element ref='keyinfo'/>
</xs:choice>
<xs:attribute name='jid' type='xs:string' use='optional'/>
<xs:anyAttribute namespace='##any' processContents='lax'/>
</xs:complexType>
</xs:element>
<xs:element name='keyinfo'>
<xs:complexType>
<xs:element name='name' minOccurs='1' maxOccurs='1' type='xs:string'/>
<xs:choice minOccurs='0' maxOccurs='1'>
<xs:element name='x509cert' type='xs:string'/>
<xs:element name='pgpdata' type='xs:string'/>
</xs:choice>
<xs:element ref='signature' minOccurs='0' maxOccurs='unbounded'/>
<xs:attribute name='jid' type='xs:string' use='optional'/>
</xs:complexType>
</xs:element>
<xs:element name='fingerprint'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute name='algo' type='xs:string' use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='signature'>
<xs:complexType>
<xs:sequence>
<xs:element ref='issuer'/>
<xs:element ref='value'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='issuer'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute name='algo' type='xs:string' use='optional'/>
<xs:attribute name='jid' type='xs:string' use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='value'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute name='method' type='xs:string' use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='sign'>
<xs:complexType>
<xs:sequence>
<xs:element ref='issuer'/>
<xs:element ref='pubkeys'/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
]]></code>
<section1 topic='XML Schemas' anchor='schema'>
<p>To follow.</p>
</section1>
</xep>