If the pubkeys PEP node does not exist already then the entity must create it. The node MUST have a NodeID of "http://www.xmpp.org/extensions/xep-0189.html#ns" &NSNOTE;.

The node SHOULD be configured as follows (see also &xep0222;):

• Items published to the node are persistent (this is done by setting the "persistent-items" option to true).
• 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").

If the user wants to control access to his/her identity (see Security Considerations) 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").

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 <publish-options/> element. However, note that not all pubsub services support this feature, since it is optional in &xep0060;.

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.

Each public key MUST be wrapped in a <KeyInfo/> element qualified by the 'http://www.w3.org/2000/09/xmldsig#' namespace as specified in &w3xmlsig;. Each <KeyInfo/> element published using PEP MUST contain a <KeyName/> element with a name that is unique for the user; this enables the key to be referenced by other XMPP Extension Protocols (for example, &xep0136;). The name MAY be the same as the value of the ItemID. 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.

Before computing the fingerprint or publishing the key, all character data between all elements in the <KeyInfo/> element MUST be removed and the XML MUST be converted to canonical form according to &w3canon;. (Any whitespace or other character data shown in the examples herein is included only for the purpose of readability.)

The value of the ItemID SHOULD be set to the fingerprint of the public key, e.g., the SHA256 hash (see &nistfips180-2;) of the key's normalized <KeyValue/>, <PGPData/> or <X509Data/> element. Therefore subscribers or other interested entities are able to request a single key by specifying its fingerprint (for example, when a subscriber is using the &xep0116; protocol).

After the account owner publishes the key, the pubsub service shall a notification to each subscriber or otherwise authorized and interested entity.