Re: [ebxml-msg] ebXML MS 2.0 Feedback

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