From ec1e5988a43257f626791c700cbc2b18841c2828 Mon Sep 17 00:00:00 2001 From: Ian Paterson Date: Fri, 2 Mar 2007 01:41:40 +0000 Subject: [PATCH] 0.5 RC1 examples, id attribute value, publish & configure git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@637 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0189.xml | 182 ++++++++++++++++++++++++++++++++++++--------------- 1 file changed, 131 insertions(+), 51 deletions(-) diff --git a/xep-0189.xml b/xep-0189.xml index 8ba57aab..d2197193 100644 --- a/xep-0189.xml +++ b/xep-0189.xml @@ -23,6 +23,12 @@ None pubkeys &ianpaterson; + + 0.5 + 2007-03-01 + ip +

Merged node creation and first publish examples; recommended the value of each <KeyName/> element and id attribute is set to the key fingerprint; added more examples

 + 0.4 2006-11-27 @@ -57,13 +63,27 @@

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 all its long-term public keys via its own server.

-

If the pubkeys PEP node does not exist already then the entity MUST create it first. 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 Security Considerations) then the entity MUST also specify an appropriate access model other than "Open".

- +

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

+

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

+

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.

+ - + + + + julietRSAkey1hash + + + ... + AQAB + + + + + @@ -84,35 +104,15 @@ - - ]]> -

Once the publishing node has been created, the entity can update the keys at any time. Each public key MUST be wrapped in a <KeyInfo/> element as specified in &w3xmlsig;. Each <KeyInfo/> element MUST contain a <KeyName/> element with a unique (for the user) name to allow the key to be referenced by other XMPP Extension Protocols.

- - - - - - julietRSAkey1 - - - ... - AQAB - - - - - - ]]> - + - julietDSAkey1 + julietDSAkey1hash

...

@@ -131,9 +131,9 @@ - + - julietX509cert1 + julietX509cert1hash CN=TAMURA Kent, OU=TRL, O=IBM, L=Yamato-shi, ST=Kanagawa, C=JP @@ -155,9 +155,9 @@ - - - julietPGPkey1 + + + julietPGPkey1hash ... ... @@ -172,9 +172,9 @@ - + - julietRSAkey1 + julietRSAkey1hash ... @@ -191,6 +191,9 @@ ]]>

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 resource that published it.

+ + + - + - julietRSAkey1 + julietRSAkey1hash ... - + - julietDSAkey1 + julietDSAkey1hash ... - + - julietX509cert1 + julietX509cert1hash ... - - - julietPGPkey1 + + + julietPGPkey1hash ... + + ]]> + + + + + + + + ]]> + + + + + + julietRSAkey1hash + + + ... + AQAB + + + + + + ]]> @@ -256,11 +293,15 @@ from='juliet@capulet.com/balcony'> - julietRSAkey1 ... - julietX509cert1 + ... + + + ... + + ... @@ -276,6 +317,33 @@ + + ]]> +

An entity MAY request one or more specific public keys by specifying their fingerprints (see Public Key Publication via PEP). The entity includes <pubkey/> child elements with 'fprint' attributes in its request:

+ + + + + + + ]]> + + + + ... + + + ... + + ]]> @@ -284,7 +352,7 @@

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:

@@ -292,12 +360,14 @@ ]]> - benvolioRSAkey + ... + + ... @@ -305,7 +375,7 @@ ]]> @@ -368,13 +438,23 @@ - - + + + + + + + + + + + + ]]>