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

[Rex Brooks <rexb@starbourne.com>]

We can provide for security in the various transports individually in 
the next version, such as XML signture in SOAP for web services 
delivery of CAP, but we can't do an overall authentication except on 
a case by case basis for this version. That is, such security as can 
be delivered between senders and receivers that already have a trust 
relationship.

Ciao,
Rex

At 11:45 AM -0800 3/24/04, Kon Wilms wrote:
>  >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.
>***********************************************************************************
>
>To unsubscribe from this mailing list (and be removed from the 
>roster of the OASIS TC), go to 
>http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgroup.php.


-- 
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request