Recently I've been looking at the XMPP encryption issue and I've got
some concerns about compatibility.
Some of this is probably familiar to people who have been tracking
this, but is added for completeness.
Currently, XMPP transmits messages as self-contained datagrams (called
stanzas) that look like this:
<message to='warlord@jis.mit.edu/Gabber@JIS.MIT.EDU' type='chat'>
<body>
Just sending a test message.
</body>
</message>
When message-oriented protection is provided, they just
encrypt the body. So, you get something that looks like:
<message to='ekr@jis.mit.edu/MIT' type='chat'>
<body>This message is encrypted.</body>
<x xmlns='jabber:x:encrypted'>
hQEOA8Ef5HX92uUXEAP/eaVgfupA3NJh8LIoMot3PK7BPRMc1zwCTK/9ss+6esS+
hxKAzJ/58A5BX98EXe6MvJ2yFKaqcwUb1BQEBGDQlLBBSZLEuhrk6+Xo/poi1q8G
w4bLaq0yekgidybYsdoyw9FonYn8VdlaYanSA+xx3KRU35bbUIbiSd667Ys9GL8D
/3ek15+Rdlg5AGfetrjEFV4Pz1NNcP792LymlH+JTdbFPEmji+Pb/UcpX6t0CIul
LJHGMVE65o2cwu8Hw1Jed7b6Bi0hYDT9LSa6ZC4Futx80xfeu9vCqCqo0TVuf7hm
Ql8Hrd9gFohUiGrWEG9lDk2C6UimE/5EqUVwn2X425uw0ogB4MhiWvrsQcStHUkt
xrkj0d5kdaT0vAzpyWYwbD4hCBNiu17yC6FHtKVRjWRCn5U8CeQjlpmY4cEXeYsd
lkzCrobNLmrxTr6z7sNzPkJB4wU2cmySOLCH407/ynlgEu4N1QlgqYQzUwpJ+lfq
BYF1+1F9a4tr6ymooqlCNdDyrN3q7r1xKem3
=yxOO
</x>
</message>
When you unpack the attached PGP message, you just get the actual
message text. So, the PGP block above is just the encryption of
"test message".
However, sensitive information is often contained in the stanzas,
so the current proposal on the table is to wrap the entire stanza
and then replicate the routing information in the unencapsulated
stanzas. This would give you something like this. (Note that
everything in [ ] is in "crypto-vision". I.e. you're seeing
something that would ordinarily be encrypted.
<message to='warlord@jis.mit.edu/Gabber@JIS.MIT.EDU' type='chat'>
<x xmlns='http://jabber.org/protocol/e2e/'>
[
<message to='warlord@jis.mit.edu/Gabber@JIS.MIT.EDU' type='chat'>
<body>
Just sending a test message.
</body>
</message>
]
</x>
</message>
Ignore the horrifying misuse of XML namespaces. That's the way the
XMPP guys do things. I understand they're fixing it.
Anyway, it's pretty clear that messages of this type will be
incompatible with other IM implementations. In particular, they'll
be incompatible with SIMPLE messages. There's obviously no
problem with the gateway translating the wrapper into whatever
SIMPLE-oid wrapper is required to indicate that message
protection has been performed, but this still leaves the embedded
payload which the gateway can't touch.
The only way that this can work properly is if SIMPLE and XMPP share
some common format that is what goes in the protected payloads.
Roughly speaking, this leaves 4 choices.
(1) Have XMPP proceed as-is. This means no compatibility btwn
XMPP and SIMPLE.
(2) XMPP and SIMPLE both implement some common format, but only
when they're interoperating.
(3) XMPP and SIMPLE use some common format in end-to-end encryption
mode but separate formats otherwise.
(4) XMPP and SIMPLE have some common payload format at all times.
Peter Saint-Andre's message of Mar 27, 2003
(http://www.jabber.org/pipermail/xmppwg/2003-March/000836.html) suggests
that he wants to do (2) above. IMHO this is a bad idea. These payload
formats have a tendency to get increasingly bloated and trying to keep
an XMPP and CPIM payload format with different syntax but the same
semantics in sync sounds really awful. (3) seems incoherent for
the same reason. Better to bite the bullet now if we're going to at all.
Note that I haven't specified what that common payload format is, since
that's a somewhat orthogonal issue. My understanding was always that
this was what CPIM MSGFMT (draft-ietf-impp-cpim-msgfmt-08.txt) was for.
I haven't really looked at MSGFMT, but a quick scan suggests it's mostly
adequate. As I understand things, SIMPLE currently uses CPIM.
From an architectural perspective, it doesn't matter what the common
format looks like as long as there is one.
-Ekr