[Standards-JIG] Questions on RFC 3923
justin-keyword-jabber.093179 at affinix.com
Tue Dec 7 19:59:13 UTC 2004
On Tuesday 07 December 2004 05:02 pm, Jens Mikkelsen wrote:
> This seems strange. How can you ensure this when the server is like an
> arbitrator between the presence informator and the presence subscribers.
> This breaks with the jabber idea, as I see it. Now you have to broadcast
> precense because you need to sign it. Right?
I'm not sure I understand what you're saying. The server still delivers the
packets on your behalf, and the recipient can verify the signature to see
that it came from you.
> Hmmm... As I see it, this destroys the jabber protocol. Wrapping the
> message in a M | Content-type: Message/CPIM
> seems to make the jabber XML despesible. There's no reason to extend the
> packet to contain more than one "to" and "from" fields.
> The same counts for presence packets.
The use of CPIM was to satisfy the requirement that RFC 3923 be interoperable
> Further regarding timestamps:
> o It MUST verify that the timestamp received is within five minutes
> of the current time.
> Dosn't this break with the idea of a message waiting on the server for
> you untill you get online?
Right, there is no support for offline messages.
> This whole RFC seems to be destroying the idea of jabber. Probably
> everyone will use encrypted IMs in a few years, so this should be
Earlier this year, I wrote a JEP to do stanza security in a more desirable
way, but it was not accepted by the JSF due to competition with RFC 3923.
You can find it here:
It is actually based on ideas from old revisions of the RFC, before PGP was
removed and it became all CPIM-ified.
What I'm considering at this point is to change my JEP into an extension of
RFC 3923, so that instead of competing with it, my JEP would only add missing
features. At the very least, I would add these: (we'll call them group A)
- Make signed presence usable
- Replay protection with offline message support
The major features remaining, then, would be: (we'll call these group B)
- non-CPIM formatting
- perhaps using XMLEnc as an alternative to S/MIME
The second feature here isn't actually in jep-secure, but it has been
something on my mind (if you haven't looked at XMLEnc yet, it's close to the
idea you mentioned).
Another thing you may have noticed is that I omitted PGP support in this
listing. Lately I've felt that we should just all use X.509 within Jabber,
since it has more support with existing protocols (particularly TLS and
XMLEnc). If we want PGP support, I think it would be easy enough to create
an extra protocol by which PGP users can trade PGP-signed self-signed X.509
certificates. However, this would be out of the scope of jep-secure and RFC
These are my current thoughts. I can easily make an extension JEP for group
A. But the major question we need to answer is whether or not group B should
More information about the Standards