OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

       Bob Miller

-----Original Message-----
From: Joseph Reagle [mailto:reagle@w3.org]
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:
Also, there an Exclusive Canonical XML document in the works that I think
would be of interest to you:

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


> 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:
A bit closer to your level of detail:
  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?

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC