[Standards-JIG] Questions on RFC 3923

Jens Mikkelsen 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
satisfy interoperablety.

> > 
[..]

> 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:
>   http://delta.affinix.com/specs/jep-secure.html
> 
> 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
XMLEnc?

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

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

> 
> 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...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://mail.jabber.org/pipermail/standards/attachments/20041208/c70205ad/attachment.sig>


More information about the Standards mailing list