JEP-xxxx: User Fingerprint

This document defines an XMPP protocol extension for communicating the fingerprints associated with public keys and certificates.


WARNING: This document has not yet been accepted for consideration or approved in any official manner by the Jabber Software Foundation, and this document must not be referred to as a Jabber Enhancement Proposal (JEP). If this document is accepted as a JEP by the Jabber Council, it will be published at <http://www.jabber.org/jeps/> and announced on the <standards-jig@jabber.org> mailing list.


JEP Information

Status: ProtoJEP
Type: Standards Track
Number: xxxx
Version: 0.0.3
Last Updated: 2006-07-17
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core
Supersedes: None
Superseded By: None
Short Name: fingerprint

Author Information

Peter Saint-Andre

Email: stpeter@jabber.org
JID: stpeter@jabber.org

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. Format
3. Initiator Use Cases
3.1. Presence Subscription
3.2. Message Exchange
3.3. Multi-User Chat
3.4. Waiting Lists
3.5. Fingerprint Management
4. Third-Party Use Cases
4.1. Roster Item Exchange
5. Security Considerations
6. IANA Considerations
7. Jabber Registrar Considerations
7.1. Protocol Namespaces
8. XML Schema
Notes
Revision History


1. Introduction

While a user's Jabber Identifier (JID) is unique across an XMPP network and a User Nickname [1] is a memorable, friendly name chosen by a user, neither of these identifiers has cryptographic significance. As explained in Prevention of JID Spoofing [2], in order to make the association between JIDs, nicknames, and handles [3] stronger, it is helpful to communicate the fingerprint derived from a user's key or certificate (e.g., an OpenPGP key or X.509 certificate). Therefore, this document specifies a format for including fingerprints whenever a user establishes initial communication with a contact or group of contacts.

2. Format

A fingerprint MUST be encapsulated as the XML character data of a <print/> element qualified by the 'http://jabber.org/protocol/fingerprint' namespace. The character data MUST be a hash of the public key or certificate itself (e.g., an OpenPGP key or X.509 certificate), hashed according to the SHA-1 algorithm as specified in RFC 3174 [4]. Here is an example:

Example 1. A Fingerprint

<print xmlns='http://jabber.org/protocol/fingerprint'>
  4D18 A46A 570C CDDB 97B5  7E27 345D 514B 3CAD DCD5
</print>
  

The entity to which the <print/> refers is the from address (no matter how encapsulated in XML) of the nearest ancestor element that specifies the sender (which might be a parent or grandparent element, e.g. the 'from' attribute of an <iq/> stanza).

3. Initiator Use Cases

In general, a user SHOULD include his or her fingerprint when establishing initial communication with a contact or group of contacts (i.e., the user has never been in communication with and does not have a prior relationship with the contact or group of contacts). Appropriate use cases therefore include:

3.1 Presence Subscription

As defined in RFC 3921, a subscription request contains only the JID of the sender:

Example 2. A Basic Subscription Request

<presence from='bard@shakespeare.lit' to='hamlet@denmark.lit' type='subscribe'/>
    

Naturally, based on the JID of the sender, it is possible for the client to pull information about the sender from a persistent data store such as an LDAP database, vcard-temp [5] node, or JEP-0154 store. However, to speed interactions, this document recommends that when a client sends a subscription request, it SHOULD include a fingerprint of the sender:

Example 3. Including Fingerprint with Subscription Request

<presence from='bard@shakespeare.lit' to='hamlet@denmark.lit' type='subscribe'>
  <print xmlns='http://jabber.org/protocol/fingerprint'>
    CFFC A717 0EAC 8051 58C4 224F 3CD5 C970 E495 30ED
  </print>
</presence>
    

Naturally, a user can include multiple fingerprints if desired:

Example 4. Including Multiples Fingerprint

<presence from='bard@shakespeare.lit' to='hamlet@denmark.lit' type='subscribe'>
  <print xmlns='http://jabber.org/protocol/fingerprint'>
    CFFC A717 0EAC 8051 58C4 224F 3CD5 C970 E495 30ED
  </print>
  <print xmlns='http://jabber.org/protocol/fingerprint'>
    4D18 A46A 570C CDDB 97B5 7E27 345D 514B 3CAD DCD5
</presence>
    

3.2 Message Exchange

When a user begins to chat with a contact but the two parties have no pre-existing relationship or prior communications (e.g., no presence subscription or previous message exchange), the user SHOULD include the fingerprint with the first message sent to the contact:

Example 5. Including Fingerprint with First Message

<message from='bard@shakespeare.lit/globe' to='hamlet@denmark.lit' type='chat'>
  <body>Hi</body>
  <print xmlns='http://jabber.org/protocol/fingerprint'>
    CFFC A717 0EAC 8051 58C4 224F 3CD5 C970 E495 30ED
  </print>
</message>
    

3.3 Multi-User Chat

Multi-User Chat [6] defines a protocol for groupchat rooms. A user specifies a "room nickname" when joining such a room (the resource identifier of the 'to' address):

Example 6. A Basic Room Join Request

<presence from='bard@shakespeare.lit/globe' to='jdev@conference.jabber.org/psa'/>
    

A user MAY specify his or her fingerprint as well.

Example 7. Including Fingerprint with Room Join Request

<presence from='bard@shakespeare.lit/globe' to='jdev@conference.jabber.org/psa'/>
  <print xmlns='http://jabber.org/protocol/fingerprint'>
    CFFC A717 0EAC 8051 58C4 224F 3CD5 C970 E495 30ED
  </print>
</presence>
    

If a user includes his or her fingerprint in the room join request, the fingerprint SHOULD also be included in any presence changes sent to the room:

Example 8. Presence Change With Fingerprint

<presence from='bard@shakespeare.lit/globe' to='elsinore@muc.shakespeare.lit/bernie'>
  <show>away</show>
  <status>Out to lunch</status>
  <print xmlns='http://jabber.org/protocol/fingerprint'>
    CFFC A717 0EAC 8051 58C4 224F 3CD5 C970 E495 30ED
  </print>
</presence>
    

A fingerprint may also be included in a MUC room invitation:

Example 9. Occupant Sends MUC Invitation

<message from='bard@shakespeare.lit/globe' to='elsinore@muc.shakespeare.lit'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <invite to='hamlet@denmark.lit'>
     <print xmlns='http://jabber.org/protocol/fingerprint'>
       CFFC A717 0EAC 8051 58C4 224F 3CD5 C970 E495 30ED
     </print>
    </invite>
  </x>
</message>
    

Although the foregoing stanza may seem to violate the rule about associating a fingerprint with the nearest ancestor element that specifies the sender's JID, the output from the MUC room does not violate that rule, since the room swaps the to and from addresses before sending the invitation to the invitee:

Example 10. MUC Room Forwards Invitation

<message from='elsinore@muc.shakespeare.lit' to='hamlet@denmark.lit'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <invite from='bard@shakespeare.lit'>
      <print xmlns='http://jabber.org/protocol/fingerprint'>
        CFFC A717 0EAC 8051 58C4 224F 3CD5 C970 E495 30ED
      </print>
    </invite>
  </x>
</message>
    

3.4 Waiting Lists

Waiting Lists [7] defines a protocol that enables a user to be informed when a contact signs up for an IM account. The user MAY include his or her fingerprint in the request so that the contact can associate a fingerprint with the request.

Example 11. IM User Requests Addition of Contact to WaitingList

<iq type='set'
    from='bard@shakespeare.lit'
    to='waitlist.shakespeare.lit'
    id='wl1'>
  <query xmlns='http://jabber.org/protocol/waitinglist'>
    <item>
      <uri scheme='tel'>+45-555-1212</uri>
    </item>
    <print xmlns='http://jabber.org/protocol/fingerprint'>
      CFFC A717 0EAC 8051 58C4 224F 3CD5 C970 E495 30ED
    </print>
  </query>
</iq>
    

Naturally, the WaitingListService SHOULD pass the fingerprint on to its InteropPartners as well:

Example 12. ServiceProvider's WaitingListService Adds New Item to WaitingList

<iq type='set'
    from='waitlist.service-provider.com'
    to='waitlist.interop-partner.com'
    id='waitinglist2'>
  <query xmlns='http://jabber.org/protocol/waitinglist'>
    <item>
      <uri scheme='tel'>contact-number</uri>
    </item>
    <print xmlns='http://jabber.org/protocol/fingerprint'>
      CFFC A717 0EAC 8051 58C4 224F 3CD5 C970 E495 30ED
    </print>
  </query>
</iq>
    

If an InteropPartner knows a contact's fingerprint when it returns results to the WaitingListService it SHOULD include the fingerprint:

Example 13. InteropPartner's WaitingListService Pushes Contact's JID to ServiceProvider's WaitingListService

<iq type='set'
    from='waitlist.interop-partner.com'
    to='waitlist.service-provider.com'
    id='jidpush1'>
  <query xmlns='http://jabber.org/protocol/waitinglist'>
    <item id='34567' jid='user@domain'>
      <uri scheme='tel'>contact-number</uri>
      <print xmlns='http://jabber.org/protocol/fingerprint'>
        CFFC A717 0EAC 8051 58C4 224F 3CD5 C970 E495 30ED
      </print>
    </item>
  </query>
</iq>
    

Finally, if the user's waiting list service knows the contact's fingerprint when it sends a notification to the user, it SHOULD include the fingerprint:

Example 14. WaitingListService Pushes Contact's JID to IM User

<message
    from='waitlist.shakespeare.lit'
    to='bard@shakespeare.lit'>
  <body>This message contains a WaitingList item.</body>
  <waitlist xmlns='http://jabber.org/protocol/waitinglist'>
    <item id='34567' jid='hamlet@denmark.lit'>
      <uri scheme='tel'>+45-555-1212</uri>
      <print xmlns='http://jabber.org/protocol/fingerprint'>
        CFFC A717 0EAC 8051 58C4 224F 3CD5 C970 E495 30ED
      </print>
    </item>
  </waitlist>
</message>
    

3.5 Fingerprint Management

In order for a user to modify his or her fingerprint and notify contacts of that change, it is RECOMMENDED for clients to use Personal Eventing via Pubsub [8]. If a personal eventing service is not available, a client SHOULD use a standalone Publish-Subscribe [9] service. If a client does not support JEP-0060 or the subset thereof specified in JEP-0163, it MAY send one <message/> stanza to each of its contacts, containing the updated fingerprint:

Example 15. Fingerprint Change

<message from='bard@shakespeare.lit/globe' to='hamlet@denmark.lit'>
  <print xmlns='http://jabber.org/protocol/fingerprint'>
    CFFC A717 0EAC 8051 58C4 224F 3CD5 C970 E495 30ED
  </print>
</message>
.
.
.
    

The client SHOULD send the messages in a staggered fashion in order to avoid server-enforced rate limiting (commonly known as "karma").

4. Third-Party Use Cases

4.1 Roster Item Exchange

If a third party knows the fingerprint for a user associated with a particlar JID in its roster, that third party SHOULD include the fingerprint when it sends the roster item to another contact in accordance with the protocol described in Roster Item Exchange [10]. [11] An example is shown below:

Example 16. Suggesting a Roster Addition

<message from='hamlet@denmark.lit' to='macbeth@england.lit'>
  <x xmlns='http://jabber.org/protocol/rosterx'> 
    <item action='add'
          jid='bard@shakespeare.lit'
          name='The Bard'>
      <print xmlns='http://jabber.org/protocol/fingerprint'>
        CFFC A717 0EAC 8051 58C4 224F 3CD5 C970 E495 30ED
      </print>
    </item>
  </x>
</message>
    

5. Security Considerations

A user fingerprint as asserted by an entity that initiates communication is, by itself, of little value, since a user can assert any fingerprint. The fingerprint becomes valuable only when it is correlated with information from other sources. One such source could be a roster item exchange received from a trusted correspondent. Another source could be a fingerprint received outside the XMPP band, for example through a real-life meeting, a telephone conversation, a key server, a certificate store, a web page known to be controlled by the user asserting the fingerprint, or a trusted third party. Naturally none of these mechanisms is necessarily fully trustable. However, in the aggregate, the communiation of fingerprints in the XMPP band and the correlation of those fingerprints with communications outside the XMPP band can serve to strengthen the web of trust and the confidence of the receiving party in the value of the provided fingerprint.

The receiving entity MUST store the full public key locally to prevent certain impersonation attacks.

6. IANA Considerations

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

7. Jabber Registrar Considerations

7.1 Protocol Namespaces

The Jabber Registrar [13] shall include 'http://jabber.org/protocol/fingerprint' in its registry of protocol namespaces.

8. XML Schema

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

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

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

</xs:schema>
  


Notes

1. JEP-0172: User Nickname <http://www.jabber.org/jeps/jep-0172.html>.

2. JEP-0165: Prevention of JID Spoofing <http://www.jabber.org/jeps/jep-0165.html>.

3. As described in JEP-0172, a "handle" is a private, unique, and memorable "petname" assigned by a contact to a user.

4. RFC 3174: US Secure Hash Algorithm 1 (SHA1) <http://www.ietf.org/rfc/rfc3174.txt>.

5. JEP-0054: vcard-temp <http://www.jabber.org/jeps/jep-0054.html>.

6. JEP-0045: Multi-User Chat <http://www.jabber.org/jeps/jep-0045.html>.

7. JEP-0130: Waiting Lists <http://www.jabber.org/jeps/jep-0130.html>.

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

9. JEP-0060: Publish-Subscribe <http://www.jabber.org/jeps/jep-0060.html>.

10. JEP-0144: Roster Item Exchange <http://www.jabber.org/jeps/jep-0144.html>.

11. As explained in JEP-0165, such a roster item exchange is called a "referral" in the terminology of petname systems.

12. 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/>.

13. 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.0.3 (2006-07-17)

Specified how to include multiple prints; removed hashtype and keytype attributes; added note about storing full key locally.

(psa)

Version 0.0.2 (2006-05-11)

Added third-party use case and security considerations to address concerns expressed by Jabber Council members.

(psa)

Version 0.0.1 (2006-04-24)

Initial version.

(psa)


END