[Standards-JIG] Questions on RFC 3923

Justin Karneges 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 
with SIMPLE.

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

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 
be done.


More information about the Standards mailing list