JEP-0189: Public Key Publishing

This document specifies how an entity may publish its public keys over XMPP.

WARNING: This Standards-Track JEP is Experimental. Publication as a Jabber Enhancement Proposal does not imply approval of this proposal by the Jabber Software Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems should not deploy implementations of this protocol until it advances to a status of Draft.

JEP Information

Status: Experimental
Type: Standards Track
Number: 0189
Version: 0.1
Last Updated: 2006-07-18
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, JEP-0060, JEP-0163
Supersedes: None
Superseded By: None
Short Name: pubkey
Schema: <http://jabber.org/protocol/pubkey/pubkey.xsd>
Wiki Page: <http://wiki.jabber.org/index.php/Public Key Publishing (JEP-0189)>

Author Information

Ian Paterson

Email: ian.paterson@clientside.co.uk
JID: ian@zoofy.com

Legal Notice

This Jabber Enhancement Proposal is copyright 1999 - 2006 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/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/>).

Discussion Venue

The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.

Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software 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 JEP 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.

Conformance Terms

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

Table of Contents

1. Introduction
2. Public Key Publication and Retrieval via PEP
3. Requesting Public Keys Directly From Another Entity
4. Security Considerations
5. IANA Considerations
6. Jabber Registrar Considerations
7. XML Schema
Notes
Revision History

1. Introduction

This JEP defines different methods an entity may use for publishing its long-term public keys:

An entity MAY have multiple keys with different formats, signatures, algorithms, strengths and expiry dates. Each client used by a user may use different keys.

2. Public Key Publication and Retrieval via PEP

An entity SHOULD use Personal Eventing via Pubsub [1] to publish all its long-term public keys via its own server.

If the pubkey PEP node does not exist already then the entity MUST create it first. In this case, the entity SHOULD specify 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='http://jabber.org/protocol/pubkey'/>
    <configure>
      <x xmlns='jabber:x:data' type='form'>
        <field var='FORM_TYPE' type='hidden'>
          <value>http://jabber.org/protocol/pubsub#node_config</value>
        </field>
        <field var='pubsub#send_last_published_item'>
          <option><value>never</value></option>
        </field>
        <field var='pubsub#access_model'>
          <option><value>roster</value></option>
        </field>
        <field var='pubsub#roster_groups_allowed'>
          <option><value>friends</value></option>
        </field>
      </x>
    </configure>
  </pubsub>
</iq>

Once the publishing node has been created, the entity can update the keys at any time. Note: Any change to the list of keys requires all keys to be republished. So clients SHOULD take care to request (see third example below) and then include all keys for the JID that were published previously by other clients (unless the keys have expired). [2]

Example 2. Entity Publishes Keys to its Server

<iq from='juliet@capulet.com/balcony' type='set' id='pub1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='http://jabber.org/protocol/pubkey'>
      <item>
        <pubkeys xmlns='http://jabber.org/protocol/pubkey'>
          <pubkey type='x509v3-sign-rsa'>
            <key> ** Base64 encoded x509 certificate containing RSA public key ** </key>
            <key> ** Base64 encoded x509 certificate containing RSA public key ** </key>
          </pubkey>
          <pubkey type='pgp-sign-dss'>
            <key> ** Base64 encoded OpenPGP certificate containing DSS public key ** </key>
          </pubkey>
          <pubkey type='ssh-rsa'>
            <key> ** Base64 encoded unsigned RSA public key ** </key>
          </pubkey>
          <pubkey type='ssh-dss'>
            <key> ** Base64 encoded unsigned DSS public key ** </key>
          </pubkey>
        </pubkeys>
      </item>
    </publish>
  </pubsub>
</iq>

Example 3. Subscriber Receives Event with Keys

<message to='romeo@montague.net/garden' from='juliet@capulet.com' type='headline'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='http://jabber.org/protocol/pubkey'>
      <item>
        <pubkeys xmlns='http://jabber.org/protocol/pubkey'>
          <pubkey type='x509v3-sign-rsa'>
            <key> ** Base64 encoded x509 certificate containing RSA public key ** </key>
            <key> ** Base64 encoded x509 certificate containing RSA public key ** </key>
          </pubkey>
          <pubkey type='pgp-sign-dss'>
            <key> ** Base64 encoded OpenPGP certificate containing DSS public key ** </key>
          </pubkey>
          <pubkey type='ssh-rsa'>
            <key> ** Base64 encoded unsigned RSA public key ** </key>
          </pubkey>
          <pubkey type='ssh-dss'>
            <key> ** Base64 encoded unsigned DSS public key ** </key>
          </pubkey>
        </pubkeys>
      </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 4. 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='http://jabber.org/protocol/pubkey'/>
  </pubsub>
</iq>

Example 5. 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='http://jabber.org/protocol/pubkey'>
      <item>
        <pubkeys xmlns='http://jabber.org/protocol/pubkey'>
          <pubkey type='x509v3-sign-rsa'>
            <key> ** Base64 encoded x509 certificate containing RSA public key ** </key>
            <key> ** Base64 encoded x509 certificate containing RSA public key ** </key>
          </pubkey>
          <pubkey type='pgp-sign-dss'>
            <key> ** Base64 encoded OpenPGP certificate containing DSS public key ** </key>
          </pubkey>
          <pubkey type='ssh-rsa'>
            <key> ** Base64 encoded unsigned RSA public key ** </key>
          </pubkey>
          <pubkey type='ssh-dss'>
            <key> ** Base64 encoded unsigned DSS public key ** </key>
          </pubkey>
        </pubkeys>
      </item>
    </items>
  </pubsub>
</iq>

3. Requesting Public Keys Directly From Another Entity

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 to the other entity:

Example 6. Location request

<iq type='get'
    id='keys1'
    to='juliet@capulet.com/balcony'
    from='romeo@montague.net/garden'>
  <pubkey xmlns='http://jabber.org/protocol/pubkey'/>
</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 7. Successful public keys response

<iq type='result'
    id='keys1'
    to='romeo@montague.net/garden'
    from='juliet@capulet.com/balcony'>
    <pubkeys xmlns='http://jabber.org/protocol/pubkey'>
      <pubkey type='x509v3-sign-rsa'>
        <key> ** Base64 encoded x509 certificate containing RSA public key ** </key>
      </pubkey>
      <pubkey type='ssh-rsa'>
        <key> ** Base64 encoded unsigned RSA public key ** </key>
      </pubkey>
    </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 8. Access to public keys denied

<iq type='error'
    id='keys1'
    to='romeo@montague.net/garden'
    from='juliet@capulet.com/balcony'>
  <pubkey xmlns='http://jabber.org/protocol/pubkey'/>
  <error code='503' type='cancel'>
    <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

4. Security Considerations

The reliable association between a user or entity and its public keys is beyond the scope of this JEP. However, it is RECOMMENDED that each client maintains 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.

5. IANA Considerations

This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [4].

6. Jabber Registrar Considerations

The Jabber Registrar [5] shall add 'http://jabber.org/protocol/pubkey' to its registry of protocol namespaces.

7. XML Schema 

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://jabber.org/protocol/pubkey'
    xmlns='http://jabber.org/protocol/pubkey'
    elementFormDefault='qualified'>

  <xs:annotation>
    <xs:documentation>
      The protocol documented by this schema is defined in
      JEP-0189: http://www.jabber.org/jeps/jep-0189.html
    </xs:documentation>
  </xs:annotation>

  <xs:element name='pubkeys'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='pubkey' minOccurs='0' maxOccurs='unbounded'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='pubkey'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='key' minOccurs='1' maxOccurs='unbounded'/>
      </xs:sequence>
      <xs:attribute name='type' type='xs:string' use='required'>
    </xs:complexType>
  </xs:element>

  <xs:element name='key' type='xs:string'/>

</xs:schema>

Notes

1. JEP-0163: Personal Eventing via Pubsub <http://www.jabber.org/jeps/jep-0163.html>.

2. The keys are long-term so they will only be republished infrequently.

3. JEP-0033: Extended Stanza Addressing <http://www.jabber.org/jeps/jep-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 Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.

Revision History

Version 0.1 (2006-07-18)

Initial version. (ip)

END