<remark><p>Merged node creation and first publish examples; recommended the value of each <KeyName/> element and id attribute is set to the key fingerprint; added fprint element and more examples</p></remark>
<li>Publishing public keys to a set of subscribers.</li>
<li>Querying another entity for its public keys.</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>
<p>If the pubkeys PEP node does not exist already then the entity MUST create it. In this case, the entity SHOULD specify that items published to the node are persistent and that the keys will only be pushed to subscribers whenever new keys are published (i.e. not when subscribers become newly available or when a new subscription is created). If the user wants to control access to his/her identity (see <linkurl='#security'>Security Considerations</link>) then the entity MUST also specify an appropriate access model other than "Open". The entity MAY create the node by including a <configure/> element when publishing a key for the first time (note: this functionality is not yet supported by &xep0060;).</p>
<p>The entity can update the keys that the node contains at any time. The value of the 'id' attribute of each <item/> element SHOULD be set to the fingerprint of the public key. i.e., the SHA256 hash (see &nistfips180-2;) of the key's normalized <KeyValue/>, <PGPData/> or <X509Data/> element (all character data <em>between</em> all elements MUST be removed and the XML MUST be converted to canonical form - see &w3canon;). Thus subscribers are able to request a single key by specifying its fingerprint (for example, when a subscriber is using the &xep0116; protocol).</p>
<p>Each public key MUST be wrapped in a <KeyInfo/> element as specified in &w3xmlsig;. Each <KeyInfo/> element published using PEP MUST contain a <KeyName/> element with a unique (for the user) name to allow the key to be referenced by other XMPP Extension Protocols (for example, &xep0136;). The name MAY be the same as the value of the 'id' attribute. However, if two <KeyInfo/> elements contain the same public key in different formats (for example, an X.509 certificate may contain an RSA key), then the name of the two keys SHOULD be the same.</p>
<examplecaption='Entity Creates Public Keys Publishing Node and Publishes an RSA Key to its Server'><![CDATA[
<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>
<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:</p>
<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>
<examplecaption='Successful public keys response'><![CDATA[
<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 ¬allowed;:</p>
<examplecaption='Access to public keys denied'><![CDATA[
<p>An entity MAY request one or more specific public keys by specifying their fingerprints (see <linkurl='#usecases-pub'>Public Key Publication via PEP</link>) as the content of <fprint/> child elements:</p>
<section1topic='Requesting Public Keys Directly From a Third Party'anchor='usecases-third'>
<p>An entity may request the public keys of another entity from a third party using the 'jid' attribute of the <pubkeys/> element to specify the JID that the keys belong to:</p>
<examplecaption='Requesting public keys from a third-party'><![CDATA[
<section1topic='Sending Public Keys Directly To Another Entity'anchor='usecases-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 <pubkeys/> 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>
<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 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>Until this specification advances to a status of Draft, its associated namespace shall be "http://www.xmpp.org/extensions/xep-0189.html#ns"; upon advancement of this specification, the XMPP Registrar shall issue a permanent namespace in accordance with the process defined in Section 4 of &xep0053;.</p>