diff --git a/xep-0189.xml b/xep-0189.xml index 011ed024..c6606486 100644 --- a/xep-0189.xml +++ b/xep-0189.xml @@ -7,7 +7,7 @@
Public Key Publishing - This document specifies how an entity may publish its public keys over XMPP. + This specification defines a method by which an entity can publish its public keys over XMPP. &LEGALNOTICE; 0189 Experimental @@ -24,6 +24,12 @@ NOT YET ASSIGNED &ianpaterson; &stpeter; + + 0.7 + 2008-03-03 + psa +

Changed temporary namespace per XEP-0053 procedures; corrected several small errors in the text and examples.

 + 0.6 2007-08-15 @@ -70,13 +76,13 @@

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.

- -

An entity SHOULD use &xep0163; to publish its long-term public keys via its own server. Processes for doing so are described in the following sections.

- -

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;):

+ +

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.

+ +

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;.

+

The node MUST be configured as follows:

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

@@ -86,7 +92,7 @@ to='pubsub.shakespeare.lit' id='create1'> - + @@ -113,7 +119,7 @@ - + julietRSAkey1hash @@ -149,15 +155,15 @@ ]]> - +

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.

+

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 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).

- + julietDSAkey1hash @@ -178,7 +184,7 @@ - + julietX509cert1hash @@ -202,7 +208,7 @@ - + julietPGPkey1hash @@ -220,7 +226,7 @@ - + julietRSAkey1hash @@ -243,14 +249,14 @@ - + - + ]]> @@ -260,7 +266,7 @@ from='juliet@capulet.com' id='items1'> - + julietRSAkey1hash @@ -295,7 +301,7 @@ from='romeo@montague.net/garden' id='items2'> - + @@ -307,7 +313,7 @@ from='juliet@capulet.com' id='items2'> - + julietRSAkey1hash @@ -325,14 +331,14 @@ ]]> - -

If an entity wishes to request the public keys of another entity and it cannot access the keys via Personal Eventing via Pubsub, then the entity MAY send an &IQ; of type 'get' to the other entity, containing an empty <pubkeys/> element qualified by the 'http://www.xmpp.org/extensions/xep-0189.html#ns' namespace &NSNOTE;.

+ +

If an entity wishes to request the public keys of another entity and it cannot access the keys via Personal Eventing via Pubsub, then the entity MAY send an &IQ; of type 'get' to the other entity, containing an empty <pubkeys/> element qualified by the 'urn:xmpp:tmp:pubkey' namespace &NSNOTE;.

- + ]]>

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 Personal Eventing via Pubsub):

@@ -341,7 +347,7 @@ id='keys1' to='romeo@montague.net/garden' from='juliet@capulet.com/balcony'> - + ... @@ -363,19 +369,19 @@ id='keys1' to='romeo@montague.net/garden' from='juliet@capulet.com/balcony'> - + ]]> -

An entity MAY request one or more specific public keys by specifying their fingerprints (see Public Key Publication via PEP) as the content of <fprint/> child elements:

+

An entity MAY request one or more specific public keys by specifying their fingerprints (see Public Key Publication via PEP) as the content of <fprint/> child elements:

- + julietRSAkey1hash julietRSAkey2hash @@ -386,7 +392,7 @@ id='keys2' to='romeo@montague.net/garden' from='juliet@capulet.com/balcony'> - + ... @@ -398,14 +404,14 @@ ]]> - +

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:

- + ]]> - + ... @@ -428,7 +434,7 @@ id='keys3' to='romeo@montague.net/garden' from='juliet@capulet.com/balcony'> - + @@ -436,12 +442,12 @@ ]]> - +

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.

- + @@ -474,7 +480,7 @@ -

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 ®ISTRAR; shall issue a permanent namespace in accordance with the process defined in Section 4 of &xep0053;.

+

Until this specification advances to a status of Draft, its associated namespace shall be "urn:xmpp:tmp:pubkey"; upon advancement of this specification, the ®ISTRAR; shall issue a permanent namespace in accordance with the process defined in Section 4 of &xep0053;.

 @@ -484,8 +490,8 @@