[JDEV] servers specifying from fields

[David Waite]

Interesting.

Actually I have a couple of things to say about this.

Currently there isn't a way to broadcast capabilities within Jabber, meaning
that there isn't some general field you can read to see that someone supports
this draft extension. Encrypted messages work because it requires presence to be
signed, which does little more than indicate the key to use for sending messages
(I say this because saying your status is 'Online' is *extremely* open for
replay - but who is going to hack into your account and set the status to signed
'Online' just to have the priviledge to receive encrypted messages?). You will
need some sort of indicator that the client supports your namespace, or to try
to propose capability reporting. Especially for encryption, you want to be
careful of clients who say 'err, hmm, no i don't support encrypted content,
could you send it again in plaintext?'

Would the client ever want to know the namespace of the encrypted block before
decrypting? If you send me an encrypted xhtml block, and I don't support rich
text...

Finally, I fear multiple extensions in a message, all encrypted. Five pgp blocks
per message will just kill bandwidth. I don't think that is really a problem
with your proposal.

Other than that, I would suggest adding the following comments:
- This is specifically for sending namespace fragments, and not for sending
entire XML documents. In particular, specify whether you can send multiple
namespace extensions through, and make sure people know they cannot do things
like insert a DTD or PI instructions (including <?xml version=1.0?> in ;-)
- Make sure for future note that clients should recognize encrypted content.
Specifically, a jabber:x:delay packet indicates a message delay - the server
cannot verify that someone isn't forging a message delay timestamp if it is
encrypted, so a client would need to have the logic to discard this information
(or even better, indicate someone is trying to fake an older message).
- Specify specifically if character encoding matters. Everything Jabber uses
UTF8, so I assume this would as well.


-David Waite

Mathew A Johnston wrote:

> Re-read megaepic.com/~johnston/nestedencrypted.txt
> The only legal encrypted element would be an x element... x elements do
> not usually include any reference to from addresses. (they should not).
>
> Mathew Johnston
>
> On Sun, 4 Mar 2001, Matthias Wimmer wrote:
>
> > Hi Mathew!
> >
> > But where is then your problem with the server setting the from-attribute?
> > Let it set the attribute of the envelove of the encrypted data and ignore
> > it if you prefere Data from within the encryted data ... but you need the
> > data also outside the encrypted package to allow bouncing of messages if
> > e.g. the receipiend has sent a message rule for auto reply.
> >
> > Tot kijk
> >    Matthias
> >
> >
> > Mathew A Johnston schrieb am 2001-03-02 19:11:09:
> > > First, I want to make sure that everyone understands the point I'm trying
> > > to make. Currently, there is no way to send encrypted messages where the
> > > encrypted message is a block of xml to be parsed upon decryption. The
> >
> > _______________________________________________
> > jdev mailing list
> > jdev at jabber.org
> > http://mailman.jabber.org/listinfo/jdev
> >
>
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev