Re: [ebxml-msg] ebXML Security

[Doug Bunting <dougb62@yahoo.com>]

Title: Reliable / Duplicate / Message Order Inconsistencies

Bob,

 

It is completely within the purview of the ebXML-msh specification to describe how XML DSIG should be (must be) used in a conforming message.  If the current specification attempts to redefine XML DSIG, we should correct those errors.  What you're saying implies we shouldn't even say what XML DSIG features should be used in a conforming message.

 

The current specification allows parallel running of the "eb" and "ds" namespace handlers and doesn't say much about how errors in each are distributed to the other.  (That seems to be an implementation issue beyond our scope.)  I believe the current text allows an implementation as you describe below except the ebXML handler should be made aware of (should be able to query) the invocation and success of the XML DSIG handler.

 

With regards to "ds" being a foreign namespace, our comments on foreign namespaces apply only to such content within ebXML elements.  The only time we embed security data from a foreign namespace is the ds:Reference elements in the eb:Acknowledgment.  That's not handled using a wildcard and is described as a required aspect of signing an acknowledgment message.

 

thanx,

    doug

 

----- Original Message -----

From: Miller, Robert (GXS)

To: ebxml-msg

Sent: Monday, 10 December 2001 11:32

Subject: [ebxml-msg] ebXML Security

As followup to my concerns about the Security section of the ebXML MSG, I offer the following observations.

 

1) The Namespace defining the Security structures in the ebXML specification is a namespace foreign to the ebXML namespace.

 

2) A conforming SOAP processor will direct processing of the security structures to the handler for that namespace, which might not be same handler as the ebXML namespace handler.  In fact, the ebXML processor might not even be aware of the presence and execution of a security handler.

 

3) End users must be free to purchase security add-on SOAP modules independent of ebXML module

 

4) None of the text in section 4.1 that relates to the definition of specific elements defined by the "ds" namespace can be normative, as the normative definition of these elements is in fact provided in a document prepared by another organization (W3).

 

--------------

 

In my opinion,

 

o - that portion of section 4.1 that addresses specific constructs defined in the"ds" namespace must be relocated to a non-normative Appendix. 

 

o - the ebXML MSG specification may (and probably should) provide guidance on the use of non-ebXML SOAP extensions (such as security).

 

o - ebXML conformance can only address conformance of ebXML specific modules. In particular, it cannot address conformance with respect to those consturcts fgoverned by a 'foreign' namespace.

 

o -  a locator reference to the W3 specification(s) for security should be provided.

 

Cheers,

            Bob Miller