« Upcoming Training and Talks | Main | SOA Security Metrics at Unatek »

Comments

asbjornu

Can't WS-Security be reused outside of the WS-* ecosystem?

Rainer Hoerbe

That is the ninth fallacy: end-to-end security will save the day. Why?
- large number of messages can be verified and decrypte only by servers, with private keys stored on servers, without human interaction. It is not feasible to enter a PIN for each message
- storage of received messages can only be based on shared secrets, because private keys are bound to a person, and organizations have to rely on roles, never a single person. Consequntly the private keys hove to be owned by servers, therefore being degraded to (locally) shared secrets.
- anyway, high availibily operation demands keystores that are not protected by passwords for fast recovery, again weakening private keys to kind of shared secrets.

Hence, from an operational perspective the conceptual differences between SSL point to point security and XML-DSig based end-to-end security is blurred. May be that one can extend the trust relationship one or to network hops further past the first application gateway to some "inside" secure zone, but the basic problem remains the same: One has to trust some shared infrastructure, that has the keys for and the power over cryptografic operations.

Reliance on SSL is in most security scenarios no disadvantage, so RESTful life may prosper:-)

Gunnar

quark - you can use the primitives of ws-security (xml encryption and xml signature) outside of ws-*

rainer -

"- large number of messages can be verified and decrypte only by servers, with private keys stored on servers, without human interaction. It is not feasible to enter a PIN for each message "

you don't need to enter a PIN for each message


"- storage of received messages can only be based on shared secrets, because private keys are bound to a person, and organizations have to rely on roles, never a single person. Consequntly the private keys hove to be owned by servers, therefore being degraded to (locally) shared secrets."

why are private keys bound to a person?

"- anyway, high availibily operation demands keystores that are not protected by passwords for fast recovery, again weakening private keys to kind of shared secrets."

keystores not protected by passwords?

"One has to trust some shared infrastructure, that has the keys for and the power over cryptografic operations."

really? why? i can aggregate and put all my customers' data at risk, because it saves the developer 5 mintues?


"Reliance on SSL is in most security scenarios no disadvantage, so RESTful life may prosper:-)"

REST will prosper in high value transactions once it has addressed the above. until then you have impedance mismatch with a message oriented programming model (REST) and a transport oritented security model (SSL).

The comments to this entry are closed.