Parties interested in exchanging encrypted data between each other via OpenPGP need to know the public key(s) of the recipients. The following section specifies a mechanism to announce and discover public keys.
-Two PEP node types are invovled: A "medatata node" is used to store meta information about + OpenPGP keys used by an entity while the actual public keys are stored in "data nodes".
-In order to announce the public key, the client needs to store - it in a PEP node. The public key data, as specified in RFC - 4880, is stored within a <pubkey/> element which is a - child element of the <pubkeys/> element qualified by the - 'urn:xmpp:openpgp:0' namespace. Note that OpenPGP's ASCII Armor is - not used, instead the XMPP client MUST encode the public key using - Base64. Clients MAY only try to store the public key if the - Personal Eventing Protocol service supports persistent-items, thus - they possibly check if the service reports the - 'http://jabber.org/protocol/pubsub#persistent-items' feature.
+The public key data, as specified in RFC 4880, is stored in a PEP data + node. Note that OpenPGP's ASCII Armor is not used, instead the XMPP client MUST encode the + public key using Base64. The id of the node MUST be "urn:xmpp:openpgp:0:public-keys:" followed + by the fingerprint string of the OpenPGP public-key contained in the data node.
+ +The OpenPGP v4 fingerprint string is obtained as follows: First the raw bytes of the
+ fingerprint are computed as specified in RFC 4880 § 12.2.. Then the bytes are
+ encoded as a hexadecimal string using upper case characters
The data node MUST contain an <pubkey/> element qualified by the 'urn:xmpp:openpgp:0' + namespace. An optional 'date' attribute holds the information about the last modification of the + key as DateTime format of XEP-0082. The element MUST include a <data/> + element which contains the data of the key Base64 encoded.
+ +In order to discover the public key of an XMPP entity, clients - send a PubSub &IQ; request to the entity's bare JID of which it - wants to know the public key.
+To update the public keys used by an entity, the metadata node is updated. Before adding a + OpenPGP key ID to the metadata node, the publisher MUST ensure that the public key is available + at the corresponding data node.
+ +The ID of the metadata node is 'urn:xmpp:openpgp:0:public-keys'. It contains a + <public-keys-list/> element qualified by the 'urn:xmpp:openpgp:0' namespace containing one + or more <pubkey-metadata/> elements. Every pubkey-metadata element MUST have a + 'v4-fingerprint' attribute, containing the OpenPGP v4 fingerprint string, and a 'date' + attribute, containing the time the key was published or updated in DateTime format of + XEP-0082. An OpenPGP V4 fingerprint MUST NOT occur in the list more than once.
+ +In order to discover the OpenPGP public keys, the interested entity first queries a remote + entities metadata note to learn about its currently annouced OpenPGP keys. Then the public + OpenPGP key(s) can be retrieved by querying the data node for a specific fingerprint.
Note that the result may contain multiple pubkey elements. Only - the public keys found in the most recent MUST be used. Requesters + the public keys found in the most recent item MUST be used. Requesters may want to limit the results to the most recent item using the 'max_items' attribute set to '1'. Clients could alternatively use &xep0059; as an alternative to 'max_items' but accoding to @@ -347,10 +400,24 @@
Entities which are subscribed to the metadata node or advertise the + "urn:xmpp:openpgp:0:public-keys+notify" feature via &xep0115; (see XEP-0060 § 9.2) + receive a notification upon a node update.
+ +A private PEP node is used to allow XMPP clients to synchronize
the user's secret OpenPGP key. Where private PEP node is defined: A
PEP node in whitelist mode where only the bare JID of the key
@@ -572,14 +639,22 @@
The PubSub nodes specified by herein SHOULD be configured to either never send the latest
- item, or to send the latest item only when a new entity subscribed. Thus the nodes
- 'send_last_published_item' configuration option SHOULD be set to either 'never' or 'on_sub' (see
- XEP-0060 The Public-Key metadata node and the Secret-Key node SHOULD be configured to either
+ never send the latest item, or to send the latest item only when a new entity subscribed. Thus
+ the nodes 'send_last_published_item' configuration option SHOULD be set to either 'never' or
+ 'on_sub' (see XEP-0060 § 16.4.4). Whenever an entity becomes aware that the metadata node has changed (e.g., by receiving a PEP
+ update from their own account), it SHOULD check that the list contains the key they use. If the
+ key has been removed, the entity SHOULD reannounce it.
Thanks to Emmanuel Gil Peyrot, Sergei Golovan, Marc Laporte, Georg - Lukas, Adithya Abraham Philip and Brian Cully for their feedback.
+ Lukas, Adithya Abraham Philip, Brian Cully and fiaxh for their feedback.The first draft of this specification was worked out and written on the wall of the 'Kymera' room in one of Google's buildings by the