This document specifies how an entity may publish its public keys over XMPP.
NOTICE: This document is currently within Last Call or under consideration by the XMPP Council for advancement to the next stage in the XSF standards process.
Series: XEP
Number: 0189
Publisher: XMPP Standards Foundation
Status:
Proposed
Type:
Standards Track
Version: 0.4
Last Updated: 2006-11-27
Approving Body: XMPP Council
Dependencies: XMPP Core, XEP-0060, XEP-0163, W3C XML Signature
Supersedes: None
Superseded By: None
Short Name: pubkeys
Wiki Page: <http://wiki.jabber.org/index.php/Public Key Publishing (XEP-0189)>
Email:
ian.paterson@clientside.co.uk
JabberID:
ian@zoofy.com
This XMPP Extension Protocol is copyright 1999 - 2007 by the XMPP Standards Foundation (XSF) and is in full conformance with the XSF's Intellectual Property Rights Policy <http://www.xmpp.org/extensions/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).
The preferred venue for discussion of this document is the Standards discussion list: <http://mail.jabber.org/mailman/listinfo/standards>.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The following keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
1. Introduction
2. Public Key Publication and Retrieval via PEP
3. Requesting Public Keys Directly From Another Entity
4. Requesting Public Keys Directly From a Third Party
5. Sending Public Keys Directly To Another Entity
6. Security Considerations
7. IANA Considerations
8. XMPP Registrar Considerations
9. XML Schema
Notes
Revision History
This document defines different methods an entity may use for publishing its long-term public keys:
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 Personal Eventing via Pubsub [1] 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".
Example 1. Entity Creates Public Keys Publishing Node
<iq from='juliet@capulet.com/balcony' type='set' id='create1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<create node='urn:xmpp:pubkeys'/>
<configure>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#node_config</value>
</field>
<field var='pubsub#persist_items'>
<value>1</value>
</field>
<field var='pubsub#send_last_published_item'>
<value>never</value>
</field>
<field var='pubsub#access_model'>
<value>roster</value>
</field>
<field var='pubsub#roster_groups_allowed'>
<value>friends</value>
</field>
</x>
</configure>
</pubsub>
</iq>
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 XML Signature [2]. 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.
Example 2. Entity Publishes an RSA Key to its Server
<iq from='juliet@capulet.com/balcony' type='set' id='pub1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:pubkeys'>
<item id='julietRSAkey1'>
<KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig#'>
<KeyName>julietRSAkey1</KeyName>
<KeyValue>
<RSAKeyValue>
<Modulus>...</Modulus>
<Exponent>AQAB</Exponent>
</RSAKeyValue>
</KeyValue>
</KeyInfo>
</item>
</publish>
</pubsub>
</iq>
Example 3. Entity Publishes a DSA Key to its Server
<iq from='juliet@capulet.com/balcony' type='set' id='pub2'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:pubkeys'>
<item id='julietDSAkey1'>
<KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig#'>
<KeyName>julietDSAkey1</KeyName>
<KeyValue>
<DSAKeyValue>
<P>...</P>
<Q>...</Q>
<G>...</G>
<Y>...</Y>
</DSAKeyValue>
</KeyValue>
</KeyInfo>
</item>
</publish>
</pubsub>
</iq>
Example 4. Entity Publishes an X.509 Certificate to its Server
<iq from='juliet@capulet.com/balcony' type='set' id='pub3'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:pubkeys'>
<item id='julietX509cert1'>
<KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig#'>
<KeyName>julietX509cert1</KeyName>
<X509Data>
<X509IssuerSerial>
<X509IssuerName>CN=TAMURA Kent, OU=TRL, O=IBM, L=Yamato-shi, ST=Kanagawa, C=JP</X509IssuerName>
<X509SerialNumber>12345678</X509SerialNumber>
</X509IssuerSerial>
<X509SKI>31d97bd7</X509SKI>
<X509SubjectName>Subject of Certificate B</X509SubjectName>
<X509Certificate>...</X509Certificate>
<X509Certificate>...</X509Certificate>
<X509Certificate>...</X509Certificate>
</X509Data>
</KeyInfo>
</item>
</publish>
</pubsub>
</iq>
Example 5. Entity Publishes a PGP Key to its Server
<iq from='juliet@capulet.com/balcony' type='set' id='pub4'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:pubkeys'>
<item id='julietPGPkey1'>
<KeyInfo xmlnss="http://www.w3.org/2000/09/xmldsig#">
<KeyName>julietPGPkey1</KeyName>
<PGPData>
<PGPKeyId>...</PGPKeyId>
<PGPKeyPacket>...</PGPKeyPacket>
</PGPData>
</KeyInfo>
</item>
</publish>
</pubsub>
</iq>
Example 6. Subscriber Receives Event with Key
<message to='romeo@montague.net/garden' from='juliet@capulet.com' type='headline'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='urn:xmpp:pubkeys'>
<item id='julietRSAkey1'>
<KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig#'>
<KeyName>julietRSAkey1</KeyName>
<KeyValue>
<RSAKeyValue>
<Modulus>...</Modulus>
<Exponent>AQAB</Exponent>
</RSAKeyValue>
</KeyValue>
</KeyInfo>
</item>
</items>
</event>
<addresses xmlns='http://jabber.org/protocol/address'>
<address type='replyto' jid='juliet@capulet.com/balcony'/>
</addresses>
</message>
Note: The stanza containing the event notification (see example above) MAY also include 'replyto' data (as specified by the Extended Stanza Addressing [3] protocol) to provide an explicit association between the published data and the resource that published it.
Example 7. Subscriber Requests Keys from Account
<iq type='get'
to='juliet@capulet.com'
from='romeo@montague.net/garden'
id='items1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:pubkeys'/>
</pubsub>
</iq>
Example 8. Entity's Server Returns Keys to Subscriber
<iq type='result'
to='romeo@montague.net/garden'
from='juliet@capulet.com'
id='items1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:pubkeys'>
<item id='julietRSAkey1'>
<KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig#'>
<KeyName>julietRSAkey1</KeyName>
...
</KeyInfo>
</item>
<item id='julietDSAkey1'>
<KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig#'>
<KeyName>julietDSAkey1</KeyName>
...
</KeyInfo>
</item>
<item id='julietX509cert1'>
<KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig#'>
<KeyName>julietX509cert1</KeyName>
...
</KeyInfo>
</item>
<item id='julietPGPkey1'>
<KeyInfo xmlnss="http://www.w3.org/2000/09/xmldsig#">
<KeyName>julietPGPkey1</KeyName>
...
</KeyInfo>
</item>
</items>
</pubsub>
</iq>
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:
Example 9. Public keys request
<iq type='get'
id='keys1'
to='juliet@capulet.com/balcony'
from='romeo@montague.net/garden'>
<pubkeys xmlns='urn:xmpp:pubkeys'/>
</iq>
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):
Example 10. Successful public keys response
<iq type='result'
id='keys1'
to='romeo@montague.net/garden'
from='juliet@capulet.com/balcony'>
<pubkeys xmlns='urn:xmpp:pubkeys'>
<KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig#'>
<KeyName>julietRSAkey1</KeyName>
...
</KeyInfo>
<KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig#'>
<KeyName>julietX509cert1</KeyName>
...
</KeyInfo>
</pubkeys>
</iq>
If the receiving entity decides not to return the public keys, it MUST return an IQ error, which SHOULD be <service-unavailable/> (to avoid divulging presence to unauthorized entities), but MAY be some other appropriate error, such as <forbidden/> or <not-allowed/>:
Example 11. Access to public keys denied
<iq type='error'
id='keys1'
to='romeo@montague.net/garden'
from='juliet@capulet.com/balcony'>
<pubkeys xmlns='urn:xmpp:pubkeys'/>
<error code='503' type='cancel'>
<service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
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:
Example 12. Requesting public keys from a third-party
<iq type='get'
id='keys2'
to='juliet@capulet.com/balcony'
from='romeo@montague.net/garden'>
<pubkeys xmlns='urn:xmpp:pubkeys' jid='benvolio@capulet.com'/>
</iq>
Example 13. Third-party responds with public keys
<iq type='result'
id='keys2'
to='romeo@montague.net/garden'
from='juliet@capulet.com/balcony'>
<pubkeys xmlns='urn:xmpp:pubkeys' jid='benvolio@capulet.com'>
<KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig#'>
<KeyName>benvolioRSAkey</KeyName>
...
</KeyInfo>
</pubkeys>
</iq>
Example 14. Third party has no copies of the keys
<iq type='error'
id='keys2'
to='romeo@montague.net/garden'
from='juliet@capulet.com/balcony'>
<pubkeys xmlns='urn:xmpp:pubkeys' jid='benvolio@capulet.com'/>
<error code='404' type='cancel'>
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
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.
Example 15. Sending public keys
<message to='romeo@montague.net/garden'
from='juliet@capulet.com/balcony'>
<pubkeys xmlns='urn:xmpp:pubkeys' jid='benvolio@capulet.com'>
<KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig#'>
<KeyValue>
<RSAKeyValue>
<Modulus>...</Modulus>
<Exponent>AQAB</Exponent>
</RSAKeyValue>
</KeyValue>
</KeyInfo>
<KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig#'>
<KeyValue>
<RSAKeyValue>
<Modulus>...</Modulus>
<Exponent>AQAB</Exponent>
</RSAKeyValue>
</KeyValue>
</KeyInfo>
</pubkeys>
</message>
The reliable association between a user or entity and its public keys is beyond the scope of this document. However, each client SHOULD maintain its own secure library of the public keys (or the "fingerprints" of the keys) it associates with other users (not necessarily JIDs).
Whenever public keys are published an identity is typically associated with a JID. Although the public keys are public information, it may be critically important for the user of the JID to keep his identity secret from all but a few specified people. Implementors MUST take great care to ensure the identity of the user of a JID is never divulged to anyone except the entities who have been permitted by the user to access the public key.
This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [4].
The XMPP Registrar [5] shall add 'urn:xmpp:pubkeys' to its registry of protocol namespaces.
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:xmpp:pubkeys'
xmlns='urn:xmpp:pubkeys'
elementFormDefault='qualified'>
<xs:element name='pubkeys'>
<xs:complexType>
<xs:choice maxOccurs='unbounded'>
<any processContents="lax" namespace="##other"/>
</xs:choice>
<xs:attribute name='jid' type='xs:string' use='optional'/>
</xs:complexType>
</xs:element>
</xs:schema>
1. XEP-0163: Personal Eventing via Pubsub <http://www.xmpp.org/extensions/xep-0163.html>.
2. XML Signature Syntax and Processing <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/>.
3. XEP-0033: Extended Stanza Addressing <http://www.xmpp.org/extensions/xep-0033.html>.
4. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
5. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <http://www.xmpp.org/registrar/>.
Added jid attribute and send use case; changed namespace
(ip)Specified that PEP nodes SHOULD be persistent
(ip)Replaced pubkey and key elements with the KeyInfo element defined in W3C XML Signature
(ip)Initial version.
(ip)END