[JDEV] servers specifying from fields

Sun Mar 4 11:02:51 CST 2001

Mathew A Johnston wrote:

> I'm not sure if I understand the significance of, "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?>"
>
> You mean whether they can send more than 1 <x> element within the
> encrypted block? Why is sending entire xml messages illegal?
>

'entire XML messages' is too vague for me to answer :-) You mean, why can't I sent
ten encrypted <message> packets to someone? It isn't in your spec - it looks like the
data that is decrypted has to be parsed, and is inserted in-place to replace a
namespace extrension.

An XML document also has only one 'root' element, so you can't just have ten messages
or ten extensions, you would have to have some root tag in order to make the block
'valid XML' in that case. Which is why it is important to make sure you decide
whether or not to support it.

>
> I think an error reporting method - ie "I dont recognise this
> namespace" would be a good thing. For the client to simply send back a
> message saying "huh? i dont understand namespace xyz?" is what I'm
> thinking. I'm thinking that there's already some support for this - i sort
> of recall hearing about this somewhere.

I don't think so. I haven't heard of it anywhere.

>
> I think we need a better method of key exchange - maybe an ability to use
> a 3rd party certificate authority. Of course, this is all client
> dependant, and does not necessarily need to have anything to do with
> jabber it's self; but I do think that we need a standard. Like you said,
> if it's easy to forge online messages that include the user's public key
> (to later be used for encrypted messages sent to the user), its hard to
> trust that we're actually sending to who we want to. Different levels of
> key security should be offered:
>
>         low: dont ever use encrypted messages
>         medium low: accept whatever key user claims on presence
>         medium: warn on change from last known key
>         medium high: 3rd party certificate authority
>         high: manual key exchange
>
> My two main concerns with jabber security are the ability to send messages
> encrypted (of any sort) and the strength of key exchange between clients.
>

well, we don't really need to use PGP encryption at all. Email has to because they
can't negotiate a session key; we can negotiate a key and use something like rjindel
or 3des. Faster, less memory requirements on the client, debatably more secure
encryption, and a signifiantly less amount of traffic.

>
> I think that if we can secure key exchange, and offer a way to send <x>
> elements encrypted (since all extentions should use x elements right?) we
> can provide a way for developers to implement their own secure private
> namespaces in their clients, to fill their needs. Right now, unless they
> implement what we're talking about, people cant really write extentions
> that are nice and secure, which sucks.

Nah, <x> is just the root element of namespaces made by Jabber (there was a published
DTD a while back with 'x' being in the jabber DTD, which is technically illegal and
made things even more confusing. )

The element is defined by the namespace , so for instance you are supposed to use:
<iq type='set'>
<vCard xmlns='vcard-temp'>....</vCard>
<iq>

or

<message to='whoever'>
<html xmlns="http://www.w3.org/1999/xhtml"><body><i>blah</i></body></html>
<body>blah</body>
</message>

-David Waite