Thanks for the insightful comments, Blair. I've embedded some of my responses to your comments regarding the three profile documents below; I'll see if I can get Andrew to address your considerations regarding the use-case document as well. Regards, Duane Blair Dillaway wrote:
SP 2.0 -- Secure Addressing
I believe the new mechanism being proposed for communication authentication and communication security requirements is counterproductive. Major industry players have already invested a lot of time in developing WS-SecurityPolicy (see WS-SecurityPolicy 1.2 , http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512) which is on a standards track in OASIS. This makes it unlikely you will find broad interest in developing or implementing the mechanism you propose. I also feel such a mechanism, which is specific to communication as part of an EPR, is too limiting. The flexibility to support other mechanisms such as WSDL, WS-MetadataExchange, etc. are important for broad adoption.
I therefore suggest you profile WS-SecurityPolicy for interoperability across the grid use cases of interest. This can include how it should be encoded within an EPR. I would also suggest the interop profile for communicating this information be in one document rather than having pieces spread over three different specs as in these drafts.
Interesting point. WS-SecurityPolicy does appear to provide what we're looking to augment the EPR with, in terms of being able to conveying secure communication requirements (and ancillary tokens). Our concern with WS-SecurityPolicy has been the ambiguity of its status within the WS-SX technical committee. Our meta-goal is to establish uniform mechanism for grouping all of the required information that one party needs for communication within one vehicle. From our perspective, the EPR is a great fit (it already contains an address URI, reference parameters, etc.). The missing piece, with respect to EPRs, is the lack of mechanism for conveying secure communication requirements (and ancillary tokens). Profiling WS-SecurityPolicy in a non-EPR-specific manner may help other mechanisms (as you mention, WSDL, or WS-MetadataExchange) to serve as means to our ends. Specifics for EPR, WSDL, and WS-MetadataExchange could then leverage such common WS-SecurityPolicy requirements.
SP 2.0-Secure Transport
I suggest removing the 'secure addressing' parts per my comments above. If that is done, I am concerned this spec comes across as little more than a profile of WS-I BSP transport security that says 'don't use weak cipher suites'. I fear people may have trouble seeing the value or why OGSA BSP -- Secure Channel isn't adequate. I think you should consider a different approach to packaging these specs and/or including a very succinct description of the value provided by this spec in the introduction.
This separation of this document from the others reflects a separation of concerns. Profiles such as the WS-I BSP have chosen to profile many semi-orthogonal specifications within one document. We argue that this is not an ideal approach as maintaining, evolving, and supporting profiles for the different components becomes less intuitive for profile designers and implementers alike. (Analogous to OO design principles where derived classes are further refinements of their parents, and one strives to keep the abstractions coherent.) Specifically, the Secure Transport document serves to * Establish a common identifier for a particular type of transport requirement * Establish processing rules for an extended form of hostname verification * Restrict allowable ciphersuites (a feature entirely inherited from this document's predecessor, the OGSA Security Profile - Secure Channel document.)
SP 2.0 -- Secure SOAP Messaging
I think a big part of the problem is flipping back and forth between requirements predicated on the presence or absence of 'message forwarding intermediaries'. It might be easier if the material were organized based on the two possible messaging models.
Point taken.
Some specific comments:
- Given the behaviors are based on the presence of message forwarding intermediaries, you really need to be precise in defining this. I expect you mean the case where the sender is transmitting a message to an end-point which it knows is not the ultimate recipient for the message body. I suspect you don't consider a transparent firewall or router to be an intermediary.
A reasonable request.
- I strongly suggest you include a brief definition of CRITICAL_SIGNING and CRITICAL_ENCRYPTION. You already mention what should be signed or encrypted and adding the supported algorithms would aid the reader in understanding what is required without having to go find the material in the WS-I BSP.
The document defines the CRITICAL_SIGNING and CRITICAL_ENCRYPTION conformance targets in the "Conformance Targets" section. The intent of referring the reader to the WS-I BSP for more specifics regarding the details for signing/encryption requirements is, again, an intentional application of separation of concerns.
- I question the requirement to encrypt of all messages. I really think you need to articulate the explicit use cases you are supporting that make this essential.
By no means does this document require the encryption of all messages. Rather, it defines a mechanism for an EPR to convey that a /particular /service requires encryption of all messages sent to /it/. (Many services may not have this requirement, and their endpoint references will reflect its absence.)
- Section 7 has seemingly contradictory requirements. I can quess at what you meant, but it would be better if you clarified it. First, you say not to use username tokens " C0701 -- Username Token credentials *SHOULD NOT be used for message level authentication* because they are not cryptographically verifiable. Then 7.2 says to use them for message sender authN "This subsection describes the *secure messaging requirements for message /SENDER/s authenticating* to /RECIEVER/s using Username Token credentials...... R0702 -- Message /SENDER/s MUST place the UsernameToken credential in the message header in accordance with the WSS UTP and Section 11 of the WS-I BSP."
Again, these are message processing rules that are to be carried out iff the endpoint reference indicates that particular action as a requirement for the referenced endpoint. ____________________________ Duane Merrill dgm4d@cs.virginia.edu <mailto:dgm4d@cs.virginia.edu> UVa Computer Science Department