RE: [ebxml-msg] ebXML Security

["Miller, Robert (GXS)" <Robert.Miller@gxs.ge.com>]

Title: Reliable / Duplicate / Message Order Inconsistencies

Doug,

 

I am not saying the ebXML MS specification should not provide advice on the use of XMLDSIG.  I am saying that such advice must not be normative, as these definitions and advice might (now or in the future) conflict with the W3 specifcations.  I do suspect that some of the content of section 4 would be better located in a 'higher level' ebXML document. 

 

"RECOMMENDED" constitutes non-normative advice (wherever it occurs in the document), and so could be present within the 'normative' section of the ebXML specification. 

 

The existing Section 4 Security Module seems to infer that this is an integral part of ebXML, whereas it is actually an integral part of another standard.  As an example of my objection to the manner in which the "ds:" security elements are presented, I refer you to the last paragraph of 4.1.1, which states: Additional ds:Signature elements MAY be present, but their purpose is undefined by this specification.  This may lead one to believe that this (ebXML) specification "defines the purpose of the specifically referenced ds:Signature elements.  It does not!  It does provide non-normative text concerning the use of these elements, perhaps taken verbatim from the normative W3 document, perhaps not.   May I suggest that 1.1.4 Caveats and Assumptions be extended to explicitly include the W3 Security work, since that knowledge is needed to comprehend section 4.  With that done, perhaps some of the text in section 4 need not even be presented in this document.

 

WRT to "ds" being a foreign namespace, the first paragraph of 2.3.6 # wildcard element content states:
"Some ebXML SOAP extension elements ...".  I concur therefore that "ds:Signature" is not governed by this paragraph (though it is governed by the SOAP definition of foreign namespaces).  The ds:Reference elements in the eb:Acknowledgement are governed by 2.3.6.

 

Cheers,

            Bob

-----Original Message-----
From: Doug Bunting [mailto:dougb62@yahoo.com]
Sent: Monday, December 10, 2001 1:50 PM
To: ebxml-msg
Subject: Re: [ebxml-msg] ebXML Security

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