moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 08:45:04 -05:00
Code Issues Releases Wiki Activity

0.11

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3725 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2009-12-17 22:38:13 +00:00
parent 9cb1267849
commit 1b0b87c8fe
1 changed files with 45 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

45
xep-0189.xml
View File

@ -24,6 +24,12 @@
&stpeter;
&dmeyer;
&ianpaterson;
<revision>
<version>0.11</version>
<date>2009-12-17</date>
<initials>psa</initials>
<remark><p>Added back example of sending public key in a message; defined presence extension to signal key generation in progress.</p></remark>
</revision>
<revision>
<version>0.10</version>
<date>2009-12-15</date>
@ -323,6 +329,45 @@
]]></example>
</section1>
<section1 topic='Sending a Public Key Directly' anchor='send'>
<p>An entity might need to send its public key to another entity, for example if it has generated a new key but does not have a way to publish the new key (or does not wish to publish the key in a world-readable fashion). In this case the entity MAY include the key directly in a &MESSAGE; stanza.</p>
<example caption='Sending a key in a message'><![CDATA[
<message from='peter@jabber.org/foo'
to='maineboy@jabber.org/bar'>
<pubkey xmlns='urn:xmpp:pubkey:1'>
<begin>2009-12-11T20:12:37</begin>
<end>2010-12-11T23:59:59</end>
<jid>peter@jabber.org</jid>
<key>
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA25/Y7oonF3+pRjZCk0cQ
lQFiUFvyMeUOnn01NLfqfBeT4xjahsxaYFPd+V8jIHtpO3nbkpfrBh5aLPCkqDzS
UFvmLaVSIMUt085kcT/Yv72BUWUGaISt7swSNfictRbVZ0k8TbXUDLIAYWN8lsie
NVxL13PS9pu3WNoORuKAV5RuzDS3djnjb6fti7fTwEUpQVwRrJXY6jNhv4c4zE3x
Pjm48gIlHbZrxuWNrXnKT6uwXnr6PJ6O3YspferJG1oA3kmOwm41yWDkalbKgkNZ
WeS+ahB/i9LIG+41CdekPpI0Kr0Ll9X7+zaPV6xzjlG8dYy7ZGm4eTL9STuWlPdL
+wIDAQAB
</key>
<print>13475c8e27399908b4447d7c52ab30822872832eba3a654f0d80e07fb4157673</print>
</pubkey>
</message>
]]></example>
</section1>
<section1 topic='Signalling Key Generation' anchor='generate'>
<p>There are several situations in which it is helpful for an entity to signal that it is currently generating a key. For example, a client that does not have access to permanent storage might generate a key on startup, but key generation might not be complete when the client sends initial presence upon establishing an XMPP session. In this case the client might signal support for the public key format in the entity capabilities data that it includes in its initial presence broadcast, but also include an indication that it is currently generating a key.</p>
<example caption='Key generation in progress'><![CDATA[
<presence from='peter@jabber.org/foo'>
<generating xmlns='urn:xmpp:pubkey:1'/>
</presence>
]]></example>
<p>After key generation is complete, the entity could publish the new key to the appropriate PEP node (if available) and signal that key generation is complete so that any interested parties can request the new key.</p>
<example caption='Key generation completed'><![CDATA[
<presence from='peter@jabber.org/foo'>
<generated xmlns='urn:xmpp:pubkey:1'/>
</presence>
]]></example>
</section1>
<section1 topic='Determining Support' anchor='support'>
<p>To advertise its support for public keys, revocations, and attestations, when replying to &xep0030; information requests an entity MUST return features for 'urn:xmpp:pubkey:1', 'urn:xmpp:revoke:1', and 'urn:xmpp:attest:1' respectively.</p>
<p>In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.</p>