[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Some suggestions regarding default security settings in ebMS 3.0
Sacha: If we are absolutely confident that no use case that requires a different security order is worth supporting, then the expected order can be required as in ebMS2. Otherwise, it seems to me that could be handled in the "gateway" conformance profile - i.e. this profile would require support for a particular order of security operations. Although conformance profiles are not defined in the main spec, it is assumed you and partners need to agree on one in order to get interoperability. The "gateway" conf profile is supposed to be the baseline for eB/eG exchanges. If we consider this is something variable enough to be a P-Mode parameter (i.e. subject to agreement at deployment time, not just at development time) then the gateway conformance profile could require this parameter to have the value specifying the desired order. So every P-Mode derived for the gateway profile would specify this order, even if the implementation can support other orders. To summarize: such a requirement could appear at 3 levels (from the most inflexible to the most flexible): (a) core spec (like in V2) (b) conformance profile (c) P-Mode parameter and value. My hunch is that (b) or (b)+(c) could be appropriate. Jacques -----Original Message----- From: Sacha Schlegel [mailto:sacha_oasis@schlegel.li] Sent: Friday, February 09, 2007 2:26 PM To: ebXML Messaging TC Subject: [ebxml-msg] Some suggestions regarding default security settings in ebMS 3.0 Dear ebMS group In todays ebXML CPPA conference call Dale talked about the ongoings in ebMS 3.0 and what ebCPPA will have to accommodate to align with ebMS 3.0. One question was formed around "given the diversity of deployment environments, what is a easy way to configure an ebMS 3.0 with a minimal or optimal set of existing or new technologies?" In this discussion, signature and encryption were identified as two key functions, and the order in which they occur. It was noted that ebMS 3.0 no longer specifies the default configuration as was defined in ebMS 2.0. ebMS 2.0 has two defaults: a) encrypt first, then sign. As a Note in section 4.1.4.5 b) the Reference for the actual ebMS 2.0 SOAP message XML digital signature was set in Section 4.1.3. The Reference <Signature> <SignedInfo> ... <Reference URI=""> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"> <XPath>not(ancestor-or-self::node()[@soap:actor="urn:oasis:names:tc:ebxm l-msg:actor:next=MSH"] | ancestor-or-self::node()[@soap:actor="http://schemas.xmlsoap.org/soap/ac tor/next"])</XPath> </Transform> </Transforms> </Reference> </SignedInfo> </Signature> Monica worded the context of all this nicely: Without such defaults in ebMS 3.0, several concerns come into play. Where does the onus fall to configure, and what implications does this have to existing or future implementations? One scenario identified was that WS-Policy and the domain specific WS-Security Policy could apply in the CPA 3.0. Yet, did ebMS 3.0 intend to implicitly extend dependencies to even more specifications to provide simple (and flexible to complex) mechanisms to support configuration of, for example, P-Mode parameters? The simpler approach would be for ebMS 3.0 to retain some default specification as existed in ebMS 2.0. A simple default allows implementations to transition functionality in an incremental way, particularly as the community gains more experience with these technologies (including those cited above). It makes sense to consider defaults to facilitate that transition in specifications and in technology adoption. Pete, who was also on the phone conference call, added that he thinks WS-Policy lacks the operation order (sign or encrypt first) as well as properly dealing with attachment references. Pete also mentioned that such default values matter on aspects such as non-repudiation, transitivity, tamper evident messages etc (Pete may have to explain better himself) so it is no easy choice how such defaults are defined. Kind regards Sacha Schlegel
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]