1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-22 07:38:52 -05:00
xeps/xep-0189.xml
Peter Saint-Andre b4cbf7dd4c author entity
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2631 4b5297f7-1745-476d-ba37-a9c6900126ab
2009-01-12 17:04:23 +00:00

557 lines
24 KiB
XML

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Public Key Publishing</title>
<abstract>This specification defines a method by which an entity can publish its public keys over XMPP.</abstract>
&LEGALNOTICE;
<number>0189</number>
<status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0060</spec>
<spec>XEP-0163</spec>
</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>
<shortname>NOT_YET_ASSIGNED</shortname>
&ianpaterson;
&stpeter;
&dmeyer;
<revision>
<version>0.8</version>
<date>2008-09-08</date>
<initials>dm</initials>
<remark><p>Change KeyInfo element from W3C XML Signature to ASCII and add signature support</p></remark>
</revision>
<revision>
<version>0.7</version>
<date>2008-03-03</date>
<initials>psa</initials>
<remark><p>Changed temporary namespace per XEP-0053 procedures; corrected several small errors in the text and examples.</p></remark>
</revision>
<revision>
<version>0.6</version>
<date>2007-08-15</date>
<initials>psa</initials>
<remark><p>More clearly explained node creation and key publication workflows.</p></remark>
</revision>
<revision>
<version>0.5</version>
<date>2007-03-05</date>
<initials>ip</initials>
<remark><p>Merged node creation and first publish examples; recommended the value of each &lt;KeyName/&gt; element and id attribute is set to the key fingerprint; added fprint element and more examples</p></remark>
</revision>
<revision>
<version>0.4</version>
<date>2006-11-27</date>
<initials>ip</initials>
<remark><p>Added jid attribute and send use case; changed namespace</p></remark>
</revision>
<revision>
<version>0.3</version>
<date>2006-11-20</date>
<initials>ip</initials>
<remark><p>Specified that PEP nodes SHOULD be persistent</p></remark>
</revision>
<revision>
<version>0.2</version>
<date>2006-09-29</date>
<initials>ip</initials>
<remark><p>Replaced pubkey and key elements with the KeyInfo element defined in W3C XML Signature</p></remark>
</revision>
<revision>
<version>0.1</version>
<date>2006-07-18</date>
<initials>ip</initials>
<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>
<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>
</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.</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 keyinfo element defined in the 'urn:xmpp:tmp:pubkey' namespace is based on the ASCII output most cryptographic libraries support. The keyinfo has three parts: a unique name, the public key data (optional) and signatures from other keys (optional). The name is the fingerprint of the public key. The unique name / fingerprint can be used to search for a key (see <link url='#pub'>Public Key Publication via PEP</link>) and MUST be written in lower case.</p>
<section2 topic='X.509 Certificate' anchor='x509'>
<p>Since X.509 has no standard fingerprint mechanisms, the SHA1 value in hex of the certificate is used as name. 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:tmp:pubkey'>
<name>428b1358a286430f628da23fb33ddaf6e474f5c5</name>
<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>OpenPGP (&rfc4880;) defines how to create fingerprints. This fingerprint is used as unique name. The public key data is the OpenPGP public key 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:tmp:pubkey'>
<name>89d099a3428481cc63fe3fa44e7df2d002b4ce44</name>
<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 name and 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 certificate for each client for &xep0178; or &xep0250;. 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.</p>
<p>The signature has an issuer and the signature data. The issuer contains the unique name / 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 am X.509 certificate signed by the key defined in the first example.</p>
<example caption='OpenPGP Public Key'><![CDATA[
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<name>571b23d99892f4566017426e92c377288ed6c983</name>
<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>
<signature>
<issuer>428b1358a286430f628da23fb33ddaf6e474f5c5</issuer>
<value method='RSA-SHA1'>
E3q/UkjRR3zcZMcIIoE2sSVKUATl26zyzO1Pmoe96p8apW91c3a0KqkQp1ZMBqXX
+e2ImqQ79CKv+9qzXitxx+V4EcniKN0ZsSR+9ZbfflxkOvmBa2rpq9hFE1NYyfuT
fsAZkRhAGlP7P5ELcvhqJ4WL6qBPYQU2NEnbVlcZSbA=
</value>
</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 must create it. The node MUST have a NodeID of "urn:xmpp:tmp:pubkey" &NSNOTE;.</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 type='set'
from='juliet@capulet.com/balcony'
to='pubsub.shakespeare.lit'
id='create1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<create node='urn:xmpp:tmp:pubkey'/>
<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' type='set' id='pub1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:tmp:pubkey'>
<item id='julietPGPkey1hash'>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<name>julietPGPkey1hash</name>
<openpgp>...</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 set to the fingerprint of the public key (the name). Therefore subscribers or other interested entities are able to request a single key by specifying its fingerprint (for example, when a subscriber is using C2C Authentication Using TLS).</p>
<example caption='Entity Publishes an X.509 Certificate to its Server'><![CDATA[
<iq from='juliet@capulet.com/balcony' type='set' id='pub3'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:tmp:pubkey'>
<item id='julietX509cert1hash'>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<name>julietX509cert1hash</name>
<x509cert>
...
</x509cert>
<signature>
<issuer>julietPGPkey1hash</issuer>
<value>
...
</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:tmp:pubkey'>
<item id='julietX509cert1hash'>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<name>julietX509cert1hash</name>
<x509cert>
...
</x509cert>
<signature>
<issuer>julietPGPkey1hash</issuer>
<value>
...
</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 type='get'
to='juliet@capulet.com'
from='romeo@montague.net/garden'
id='items1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:tmp:pubkey'/>
</pubsub>
</iq>
]]></example>
<example caption='Entity&apos;s Server Returns Keys to Subscriber'><![CDATA[
<iq type='result'
to='romeo@montague.net/garden'
from='juliet@capulet.com'
id='items1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:tmp:pubkey'>
<item id='julietPGPkey1hash'>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<name>julietPGPkey1hash</name>
...
</keyinfo>
</item>
<item id='julietX509cert1hash'>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<name>julietX509cert1hash</name>
...
</keyinfo>
</item>
</items>
</pubsub>
</iq>
]]></example>
<example caption='Subscriber Requests Specific Key'><![CDATA[
<iq type='get'
to='juliet@capulet.com'
from='romeo@montague.net/garden'
id='items2'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:tmp:pubkey'>
<item id='julietX509cert1hash'/>
</items>
</pubsub>
</iq>
]]></example>
<example caption='Entity&apos;s Server Returns Key to Subscriber'><![CDATA[
<iq type='result'
to='romeo@montague.net/garden'
from='juliet@capulet.com'
id='items2'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:tmp:pubkey'>
<item id='julietX509cert1hash'>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<name>julietX509cert1hash</name>
...
</keyinfo>
</item>
</items>
</pubsub>
</iq>
]]></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:tmp:pubkey' namespace &NSNOTE;.</p>
<example caption='Public keys request'><![CDATA[
<iq type='get'
id='keys1'
to='juliet@capulet.com/balcony'
from='romeo@montague.net/garden'>
<pubkeys xmlns='urn:xmpp:tmp:pubkey'/>
</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>):</p>
<example caption='Successful public keys response'><![CDATA[
<iq type='result'
id='keys1'
to='romeo@montague.net/garden'
from='juliet@capulet.com/balcony'>
<pubkeys xmlns='urn:xmpp:tmp:pubkey'>
<keyinfo>
...
</keyinfo>
<keyinfo>
...
</keyinfo>
</pubkeys>
</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 type='error'
id='keys1'
to='romeo@montague.net/garden'
from='juliet@capulet.com/balcony'>
<pubkeys xmlns='urn:xmpp:tmp:pubkey'/>
<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;fprint/&gt; child elements:</p>
<example caption='Specific public keys request'><![CDATA[
<iq type='get'
id='keys2'
to='juliet@capulet.com/balcony'
from='romeo@montague.net/garden'>
<pubkeys xmlns='urn:xmpp:tmp:pubkey'>
<fprint>julietX509cert1hash</fprint>
<fprint>julietX509cert2hash</fprint>
</pubkeys>
</iq>
]]></example>
<example caption='Successful specific public keys response'><![CDATA[
<iq type='result'
id='keys2'
to='romeo@montague.net/garden'
from='juliet@capulet.com/balcony'>
<pubkeys xmlns='urn:xmpp:tmp:pubkey'>
<keyinfo>
...
</keyinfo>
<keyinfo>
...
</keyinfo>
</pubkeys>
</iq>
]]></example>
</section1>
<section1 topic='Requesting Public Keys Directly From a Third Party' anchor='third'>
<p>An entity may 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 type='get'
id='keys3'
to='juliet@capulet.com/balcony'
from='romeo@montague.net/garden'>
<pubkeys xmlns='urn:xmpp:tmp:pubkey' jid='benvolio@montague.net'/>
</iq>
]]></example>
<example caption='Third-party responds with public keys'><![CDATA[
<iq type='result'
id='keys3'
to='romeo@montague.net/garden'
from='juliet@capulet.com/balcony'>
<pubkeys xmlns='urn:xmpp:tmp:pubkey' jid='benvolio@montague.net'>
<keyinfo>
...
</keyinfo>
<keyinfo>
...
</keyinfo>
</pubkeys>
</iq>
]]></example>
<example caption='Third party has no copies of the keys'><![CDATA[
<iq type='error'
id='keys3'
to='romeo@montague.net/garden'
from='juliet@capulet.com/balcony'>
<pubkeys xmlns='urn:xmpp:tmp:pubkey' 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;pubkeys/&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 to='romeo@montague.net/garden'
from='juliet@capulet.com/balcony'>
<pubkeys xmlns='urn:xmpp:tmp:pubkey' jid='benvolio@montague.net'>
<keyinfo>
...
</keyinfo>
<keyinfo>
...
</keyinfo>
</pubkeys>
</message>
]]></example>
</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 may 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>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='ns'>
<p>Until this specification advances to a status of Draft, its associated namespace shall be "urn:xmpp:tmp:pubkey"; upon advancement of this specification, the &REGISTRAR; shall issue a permanent namespace in accordance with the process defined in Section 4 of &xep0053;.</p>
</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:tmp:pubkey'
xmlns='urn:xmpp:tmp:pubkey'
elementFormDefault='qualified'>
<xs:element name='pubkeys'>
<xs:complexType>
<xs:choice>
<xs:element name='fprint' type='xs:string'/>
<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='x509' type='xs:string'/>
<xs:element name='openpgp' type='xs:string'/>
</xs:choice>
<xs:element ref='signature' minOccurs='0' maxOccurs='unbounded'/>
</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='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:schema>
]]></code>
</section1>
</xep>