Morris Riedel wrote:
Hi security folks,
reading certain elements of the IIRM, strawman, and following discussions on the list - I see there is still no common agreement on SOAP / HTTP(S) in some areas.
Trying to pick up the thread, I have read it now (not necessarily understood :-)... I skimmed PGI_COMM v0.3, mainly asking to clarify whether things are in scope. Note the difference between PKC validation is that in Globusy grids the web service must have the whole CA certificate chain installed from the EE cert to a self signed root; for a proxy the client is required to supplement the chain by sending the intermediate certificates (viz, the user certificate and intermediate proxies). There are cases where this provides additional security. Thus a web service provider needs the CA hierarchy installed - this is (being) documented by CAOPS. In a sense the proxy hierarchy underneath it is more dynamic. In a sense this makes it more usable at the cost of some loss of security. One other point, nobody so far (that I could see) mentioned the gLite delegation service. This would provide a way to keep delegation but still have SSL/TLS sockets. One other point. Most HTTPS/SOAP connections in practice are opened on demand. Every time the client makes a call (I don't believe anyone ever implemented notifications, instantiated from the server), a new SSL socket is negotiated. This turns out to be comparatively expensive, and there are suggestions for how to improve this. Is this within the scope of the document? There are proposals for streaming SOAP, is that within the scope of this document? Support for this would be useful for some of our applications. One other point, turns out there is some debate about the role of the trust anchors in SAML-based trust federations (Shibboleth ones specifically). Their approach is in practice often distinct from typical grid PKIs. Is this within the scope of the document? Is the work supposed to be specific to SOAP or are other things carried by HTTPS or HTTPG relevant? One thing that would be useful is to have an overview of which WS-* are actually implemented in usable libraries. I will not touch WS-Anything unless it has a (preferably open source) implementation in C++ which interoperates with a Java ditto (usually Java supports WS-Anything first). Regards --jens