RE: [ebxml-msg] Some suggestions regarding default security settings in ebMS 3.0

Sacha,

 

I'd also suggest there is a default profile - that applies if no profile
is present.

 

This should be a general purpose profile with some typical minimal
defaults.

 

In practice we've kinda had this in ebMS implementations today - just
noone

had really quantified it before.

 

If we did this - older v2.0 ebMS would conform to that profile by
default and a

v3 ebMS would then interact on that basis.

 

DW

"The way to be is to do" - Confucius (551-472 B.C.)

-------- Original Message --------
Subject: RE: [ebxml-msg] Some suggestions regarding default security
settings in ebMS 3.0
From: Sacha Schlegel <>
Date: Thu, February 15, 2007 2:53 am
To: "Durand, Jacques R." <>
Cc: ebXML Messaging TC <>

Hi Jacques

Am Dienstag, den 13.02.2007, 16:46 -0800 schrieb Durand, Jacques
R.:
> 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.

I mixed them up in my email as Dale pointed out. So for the records:

As noted in Note in section 4.1.4.5 in ebMS 2.0 sign first then
encrypt.

> 
> 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:] 
> 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
>