[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Some suggestions regarding default securitysettings in ebMS 3.0
I think several features need to be added to deal with CPP and CPA support for ebMS 3.0 1. The MPF URI value to be used in "pull" mode. 2. Some changes in Transport to allow "pull" mode. 3. A place for the ebMS MEP value. 4. Probably some place to indicate the conformance profiles that are supported for a DeliveryChannel. 5. Depending on conformance profile, possible other values TBD. I think all of these matters remain to be resolved in the CPPA TC meetings this month and in March. The role of WS-Policy is tricky. Some aspects of WSS (used in ebMS 3.0) have domain policy assertions defined. Some aspects of WS-RX may have domain policy assertions. Use of these policy assertions to express policy alternatives for ebMS may have the advantage (in some cases) of not having to invent something new. However, where we already have enumerated values (such as for algorithms and strengths), domain policy is redundant (and a bit verbose also!). So we need to continue these discussions in CPPA. I think one main issue is how to handle ebMS configuration for explicit enumeration of the parts/elements/attachments to be signed or encrypted. In CPPA 2.0 we had the following mechanism in Packaging: <xsd:complexType name="ConstituentType"> <xsd:sequence> <xsd:element ref="tns:SignatureTransforms" minOccurs="0"/> <xsd:element ref="tns:EncryptionTransforms" minOccurs="0"/> </xsd:sequence> <xsd:attribute name="idref" type="xsd:IDREF" use="required"/> <xsd:attribute name="excludedFromSignature" type="xsd:boolean" default="false"/> <xsd:attribute name="minOccurs" type="xsd:nonNegativeInteger"/> <xsd:attribute name="maxOccurs" type="xsd:nonNegativeInteger"/> </xsd:complexType> Notice that we had an optional attribute called "excludedFromSignature" and we also had a way to indicate both Encryption and Signature Transforms. What we do not have is a way to indicate specific elements to be signed, specific SOAP headers to be signed, SOAP headers to be encrypted, and a few more features. We could also add and enhance this Packaging component of CPP/CPA. This would allow ebMS configuration without "requiring" WS-Policy processing capabilities (such as those found in the Apache project Neethi.) (Actually it has always been implementation dependent just what matching capability processing features are needed as part of the CPP to CPA formation and negotiation processes.) We have not yet considered this option so there is more to take up in CPPA before the choices have all been presented and their tradeoffs discussed. Dale Moberg > 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. Will these conformance profiles have standardised forms or structures or unique ways to reference them? Are they part of ebXML MS or ebXML IIC TC? Would you think that theses conformance profiles will then be referenced in the ebXML CPA? In the ebXML CPA team of course we want to have everything ready once we come to a final ebXML CPA. The idea being that we only need to agree on the values we put in the ebXML CPA (which can include to set the conformance profile) and than there is no need to later have yet another agreement (discussion, email exchange or any other form of collaboration) to achieve interoperability. > > 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. > The way I understood the ebXML CPA phone conference call where these questions were raised was if I want to use ebMS 3.0 and ebXML CPA 3.0 must an application supporting both implement yet another WS-* specification (I think WS Policy was referenced) or can we have all ebMS 3.0 configurations done in plain ebXML CPA. So, Dale Monica please help out if I miss the point here. I think as long as these configurations values can be configured without the absolute need to have another WS-* spec implemented (Monicas concern was as, far as I understand, that that requirement could have further consequences, eg if you have to implement WS-A for the configuration only then you naturally would also need implement WS-B, WS-C etc, Monica maybe you clarify again) then for the ebXML CPA people that would be OK and it is the ebXML MS people task to find the right place to place those settings. Sorry I do not know about the P-Modes enough but your hunch is that they would not be in the spec. Hope this makes sense and sorry that I did not keep up with ebMS 3.0 specs. Sacha > 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]