Re: [ebxml-msg] ebXML MS 2.0 Feedback

[Doug Bunting <dougb62@yahoo.com>]

Chaemee,

 

We apologise for not responding immediately but have not had a chance to discuss or research your first issue.  If I remember correctly, the reasons were: 1) the new schema is incompatible with the old and so may be hosted at a new location and 2) the old location (ebXML.org) is harder to update at the moment.  No, I didn't check the archives and I'm not positive that was all of the reasons or even that these were among the reasons.

 

On your second issue, we're not defining a canonicalization algorithm twice, we're describing how the signed material is canonicalized (the Transforms list) and then how the SignedInfo element is handled.  In the dsig specification, see also:

 

http://www.w3.org/TR/xmldsig-core/#sec-o-Simple

[s03] The CanonicalizationMethod is the algorithm that is used to canonicalize the SignedInfo element before it is digested as part of the signature operation.

 

thanx,

    doug

 

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

From: Chaemee Kim

To: ebXML Msg

Sent: Monday, February 04, 2002 11:39 PM

Subject: [ebxml-msg] ebXML MS 2.0 Feedback

Dear ebXML MS members,

 

I sent one question for ebXML MS 2.0, but no one reply my question.

As a member, I think you guys have a responsibility to reply for the any feedback.

Making new ebXML version is very important, but gethering feedback is also valuable not to make same mistake.

If it is akward question, let me know the reason.

I'm sorry I don;t have time to attend tele-conference and WG activity, but I'm trying my best to give you feedback from our implementation experience.

 

[Q 1] Why doesn't ebXML MS use ebxml.org URL to refer msg-header-2.0xsd?

 

[Q 2] It is unclear why we have to define again for canonicalization Algorithm in <Transform>, even though is it defined in <CanonicalizationMethod>. In version 1.0, there was no redundant definition for that.

 

4.1.3. Signature Generation

<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>

       <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>

       <Reference URI="">

         <Transforms>

           <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>

           <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">

            <XPath> not(ancestor-or-self::()[@SOAP:actor=

                &quot;urn:oasis:names:tc:ebxml-msg:actor:nextMSH&quot;]

                     | ancestor-or-self::()[@SOAP:actor=

                &quot;http://schemas.xmlsoap.org/soap/actor/next&quot;])

            </XPath>

           </Transform>

          <Transform Algorithm="http://www.w3.org/TR/1999/REC-xslt-19991116">

            <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

              <xsl:strip-space elements='*'/>        <!-- Strip whitespace. -->

              <xsl:template match='node()|@*'>       <!-- The identity transform. -->

               <xsl:copy> <xsl:apply-templates select='@*'/><xsl:apply-templates/> </xsl:copy>

              </xsl:template>

            </xsl:stylesheet>

          </Transform>

           <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>

                                                                 </Transforms>

 

 

http://www.w3.org/TR/xmldsig-core/#sec-X509Data

4.3.3.4 The Transforms Element

The optional Transforms element contains an ordered list of Transform elements; these describe how the signer obtained the data object that was digested. The output of each Transform serves as input to the next Transform. The input to the first Transform is the result of dereferencing the URI attribute of the Reference element. The output from the last Transform is the input for the DigestMethod algorithm. When transforms are applied the signer is not signing the native (original) document but the resulting (transformed) document.

Chaemee Kim
KTNET