[Standards-JIG] Questions on RFC 3923
gyldenskjold at mail.dk
Wed Dec 8 00:14:04 UTC 2004
On Tue, 2004-12-07 at 20:59, Justin Karneges wrote:
> 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.
I didn't mean sign it, but encrypt it with B's public key. But I see
now, that the RFC doesn't talk of encryption only sign. So this
shouldn't create a problem.
> The use of CPIM was to satisfy the requirement that RFC 3923 be interoperable
> with SIMPLE.
In my opinion it is more important to maintain the Jabber model than to
> 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.
Yes it looks a bit like, what I had in mind as well. This seem much more
intuitivly and "jabber-like".
I am currently working on my bachelor project - an encrypted jabber
client with more and I just hate to use the CPIM wrapper, but better do
what the rfc says. ;o)
> 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).
As I see it the non-CPIM part is the most important.
I am not that much in to the S/MIME. I looked a bit at the RFC, but not
enough to se whats the problem with it. What are pros and cons? As I
read it, you can use RSA with S/MIME. Right? Do you have anymore info on
> 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
This seems reasonable.
I don't think asynchronical encryption is completely satisfactory for
Jabber. I see IM's as being very usefull in distributed systems with
filesharing etc. I think this is the future. If files are being
transfered all the time, synchronical encryption seems more efficient.
As I see it asyncronical encryption should be used for messages, and
single file transfers, but when multible files/video/voice are being
send to multible persons the protocol should use synchronical
> 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.
Thanks for your thoughts! I think that group B is the most important. If
every message,file,video,voice you send is encrypted the CPIM or
CPIM-like wrap will come to a cost of speed. This is just my opinion.
Jens Mikkelsen <gyldenskjold at mail.dk>
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the Standards