OASIS ebXML Messaging Services TC

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 



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

Sacha Schlegel wrote:

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


Hi Sacha,

The TC found that the ebMS 2.0 default on protection ordering was
actually sign, then encrypt.

The current ebMS 3.0 draft appears to use this as the order default
across any conformance profile.

So the updates proposed for defaults in the Gateway conformance profile
will mainly deal with providing defaults on what an application will
sign and what it will encrypt (when the end users involved do not
otherwise agree on referenced parts, elements, or attachments).

Am Mittwoch, den 14.02.2007, 16:20 -0700 schrieb Dale Moberg:
> Sacha Schlegel wrote:
> 
> 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
> 
> 
> Hi Sacha,
> 
> The TC found that the ebMS 2.0 default on protection ordering was
> actually sign, then encrypt.

Correct. As note in section 4.1.4.5 of ebMS 2.0 sign first and then
encrypt.

sorry for the mix up.

> 
> The current ebMS 3.0 draft appears to use this as the order default
> across any conformance profile.

ok

> 
> So the updates proposed for defaults in the Gateway conformance profile
> will mainly deal with providing defaults on what an application will
> sign and what it will encrypt (when the end users involved do not
> otherwise agree on referenced parts, elements, or attachments).

ok sounds good to me. So this would be like that XPath expression that
was provided for ebMS 2.0, at least for the signing part.

Sacha

> 
>