RE: FW: [ebxml-msg] ebMS_v1.091.zip

Title: RE: FW: [ebxml-msg] ebMS_v1.091.zip

Good People,

Given my concern with the manner in which XMLDSIG is presented in the ebXML MS, I sent a copy of the V1.091 document and my concerns to Josep Reagle, a leader of the XMLDSIG effort.  Below are his comments.

Cheers,

       Bob Miller

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

From: Joseph Reagle [mailto:]

Sent: Monday, December 17, 2001 11:30 AM

To: Miller, Robert (GXS)

Subject: Re: FW: [ebxml-msg] ebMS_v1.091.zip

On Thursday 13 December 2001 10:30, you wrote:

> Much of the content of this section relies on the XMLDSIG work, and uses

> elements properly ascribed to the XMLDSIG namespace.  I raised some

> issues with the manner in which this referenced work was included in our

> specification, but have not received support for change.  Perhaps I'm

> tilting at windmills, but I'd like to hear your opinion on the manner of

> presentation of this material in the ebXML MS document.

Ok, but keep in mind my comments are from a very quick review and might be 

a lot of hot air -- to continue the windmill metaphor <smile/>!

> If you have no issue with our work, you need not respond. I don't think

> you can post to our list, so if you do have comments, send them to me for

> posting on our list.

First, I'd note that Canonical XML is now a REC and you should use the 

latest URI:

  http://www.w3.org/TR/2001/REC-xml-c14n-20010315

Also, there an Exclusive Canonical XML document in the works that I think 

would be of interest to you:

  http://www.w3.org/2001/10/xml-exc-c14n#

> 1) The Namespace defining the Security structures in the ebXML

> specification is a namespace foreign to the ebXML namespace.

If you mean xmldsig, yes.

> 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.

Probable.

> 3) End users must be free to purchase security add-on SOAP modules

> independent of ebXML module

Sounds good.

> 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).

> o - that portion of section 4.1 that addresses specific constructs

> defined in the"ds" namespace must be relocated to a non-normative

> Appendix.

When I first read Security Core Module I did find it awkward/confusing that 

it was specifying things like, "Create a ds:SignedInfo element with 

ds:SignatureMethod" and "The ds:SignatureMethod element SHALL be present". 

That sounds like you are redfinging xmldsig. However, your choice of 

algorithms and transforms is normative and I don't think should be in an 

appendix. However, I think there's an easy solution if you consider two of 

your points. Xmldsig is a seperate handler, and it is passed various 

parameters and if this section were written with that understanding I think 

that would be an improvement.

At its simplest, one could use something like this:

  http://www.w3.org/TR/xmldsig-p3p-profile/#sec-Signature

A bit closer to your level of detail:

  http://odrl.net/1.0/ODRL-10-HTML/index.html

  2.11 "ODRL Security Model"

> o -  a locator reference to the W3 specification(s) for security should

> be provided.

Not sure what a "locator reference" is?