[Standards-JIG] The Great Encryption Debate

Ian Paterson ian.paterson at clientside.co.uk
Fri Aug 12 13:41:48 UTC 2005


IMHO it would be neither possible nor desirable to obtain consensus on a
single method of "Associating a key or certificate with a JID".
Corporations that have issued X.509 certs to all their employees will
want Jabber to support them. Many people here (including me) like the
idea of a new distributed XMPP-based web of trust. Some people will want
to use their existing PGP keys and WoT. In the future governments or
international organisations might propose completely new and very
popular schemes...

This implies we could usefully divide into four the list of separate
problems in this space:

   1. Publishing public key blobs (including certificates)
   2. Methods for associating a key with a JID
   3. Negotiating which public keys entities will use
   4. Encryption of XMPP using agreed keys to authenticate

1. Publishing public key blobs (including certificates)

We need to provide a couple of standard protocols to do this in-band for
example:

   A. disco#pub-sub
   B. in-message

We should also allow clients to import keys out-of-band (e.g., from an
external CA or public web of trust).

The in-band protocols should allow people to distribute multiple keys
from different systems (XMPP-WoT, X.509, PGP, CAcert...). The protocols
do not need to understand the formats of the key blobs they distribut,
but they should support an extensible list of standard format names.

2. Methods for associating a key with a JID

This involves extracting the raw public (RSA or DSA) key from the
published data and verifying whether it belongs to a specified JID
(either in-band or out-of-band). There will be as many methods of doing
this as there are key formats and authorities/WoTs. Clients should
maintain their own databases of trusted key fingerprints.

We should develop a new XMPP-native distributed key-association
architecture and protocol that leverages rosters and the existing
network of XMPP servers (linking signatures of key fingerprints into a
Web). But we should bear in mind that not all XMPP servers will support
the protocol.

3. Negotiating which public keys entities will use

Alice may not support all methods for associating a key with a JID (and
Bob may not have access to all his private keys). So, before engaging in
encrypted communications, entities must negotiate which (if any) keys
they are prepared to accept for authentication.

4. Encryption of XMPP using agreed keys to authenticate

Three very different e2e cases have been identified:

   A. One-to-one (including session, offline and object encryption)
   B. One-to-many
   C. Many-to-many


The scope of JEP-0116 is points 1B, 3 and 4A (now including object
encryption - see
http://www.clientside.co.uk/jeps/jep-0116/jep-0116.html). We need a
separate JEP for point 1A (JEP-0116 currently gives some hypothetical
examples). Together these points represent the 'low-hanging fruit'. They
are all that is required to implement fully secure one-to-one stanza
exchanges. I recommend we direct our (limited) resources there first.

We also need JEPs for points 2 (XMPP-WoT, and perhaps JSF-CA?), 4B and
4C. But these are all difficult problems for which ideal solutions
almost certainly do not exist. These JEPs may take more time, and it
will take even longer to implement and roll out the required server-side
functionality.

- Ian




More information about the Standards mailing list