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