Message encryption -- was RE: [emergency-comment] RE: [CAP] RE: CAP-list digest...)

["Kon Wilms" <kon.wilms@ndsamericas.com>]

>sharp stick and a poke in the eye. In order for this thing to work we NEED
>to settle down, stay engaged and get the freaking spec completed to
>EVERYONE's satisfaction, or we're just blowing smoke up each other's
skirts.
>As my pig farmer relatives used to say, (sorry Art, no Roman Generals in
the
>family), "Life is not about how fast you run, or how high you climb, but
how
>well you bounce."

Well the point of contention is listed below. There is no way to do
signed/authenticated CAP messages.

Quite frankly, without encrypting the entire message on a different layer,
there is no way to securely hash a XML file and transport it over networks
which provide no sender verification anyway -- even if the hash is stuffed
into the XML file itself.

Any generated hash can be circumvented by a MITM (man in the middle) attack
(just gen a fake message and stuff a new hash into it). A MITM could be a
compromised or spoofed server in a two-way network or a jammer in a one-way
network (or combination of both).

In my personal opinion this is clearly outside the scope of the CAP message,
and any vendor worth their salt should be able to easily pick one of many
standards available to encrypt messages (PKI, symkey, SSL, etc.) where
needed, no matter the transport used. You can do this dependent on the
transport, or not. Pick your option - pipe or content encryption (or both).
Nothing complex or non-standard for implementation here.

Someone mentioned HTTP in a previous post - this is the same concept. How
many servers do you see using self-signed HTML pages with an embedded hash
or such, vs. using SSL to encrypt vanilla HTML pages. A big fat zero.

Cheers
Kon

> >> So, what you're saying is that CAP *does not* provide any
> >>mechanism or facility for doing authentication of messages in a manner
> >>which is independent of the transport mechanism. If you want signed
> >>messages, you must use a transport, like SOAP, that supports signed
> >>messages. Thus, the odd mention of WSSE in the specification is really
> >>just a non-normative hint to users of SOAP which reminds them that
> >>they can use SOAP to transport and sign CAP bodies. CAP itself,
> >>doesn't deal with the issue of signing CAP messages nor does it deal
> >>with encryption.


***********************************************************************************
Information contained in this email message is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the postmaster@nds.com and destroy the original message.
***********************************************************************************