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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-poc message

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


Subject: Re: dsig and SOAP2.1


Dale,

The Transforms you specified:

<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>/descendant-or-self::node()[not(ancestor-or-self::Signature)
and not(ancestor-or-self::TraceHeaderList)]</XPath>
</Transform>
</Transforms>

works because the first Transform removes the Signature element
containing that Transform element and the second Transform
removes only the TraceHeaderList (if present).

If security (dsig) is being used in absence of Via and/or TraceHeaderList
then the first Transform alone should suffice.

e.g.

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

It would also be the case that most, if not all implementations of dsig 
would support this manner of transform since XPath transform is not
REQUIRED of an XMLDSig implementation. If everyone's dsig implementation
supports XPath transforms, then the issue is moot. However, I think that
it would be best if we used an XPath expression that was "more correct"
than the one you used (and that I specified, yiles;-) in v0.98b.

Thus, the ones I cited, or possibly the following:

<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>/descendant-or-self::node()[not(ancestor-or-self::eb:Via
or ancestor-or-self::eb:TraceHeaderList)]</XPath>
</Transform>
</Transforms>

Cheers,

Chris

Dale Moberg wrote:
> 
> Thanks, Chris, for commenting on
> the Via element excision for the
> n-intermediary case, n>0.
> Apparently Sid has decided that
> the intermediaries in hl7
> will not be using either
> Via or TraceHeaderList at the
> Vienna POC.
> 
> POCers, I am attaching a sample
> signed ebxml header for examination
> prior to the Maryland meeting
> for participants in the hl7
> scenario. We are using slightly
> different Xpath transforms than
> Chris; should be equivalent
> effect though. This sample is
> produced in a standalone header
> signing environment, but by
> Monday we should have it
> integrated with our servlet
> environment for the POC.
> This output is based on the IBM
> alphaworks xss4j code, using
> straightforward, unhacked
> template methods.
> 
> We are not using the Apache
> SOAP4J 2.1 so can't comment about
> its interaction issue.
> 
> To keep list traffic under control,
> please send questions
> to me and/or Jeff Turpin until
> we find something of general interest.
> 
> -----Original Message-----
> From: cferris@xtacy.East.Sun.COM [mailto:cferris@xtacy.East.Sun.COM]On
> Behalf Of christopher ferris
> Sent: Thursday, April 26, 2001 11:05 PM
> To: ebxml-poc@lists.ebxml.org
> Cc: Ralph Berwanger
> Subject: dsig and SOAP2.1
> 
> If anyone is using SOAP2.1 and having difficulty
> with the signature verification (as I was struggling
> with until a few moments ago), the problem may lie
> in the fact that the org.apache.soap.Envelope.marshall()
> method is modifying the document instead of
> simply writing it out from the DOM tree. Thus, the
> digest would be significatly different when validating.
> 
> In any event, I have XMLDSig signing and validation working
> in my MSH implementation which is built on Apache SOAP4J 2.1.
> 
> Note that the Message Service spec (0.98b and 0.99)
> will need to be changed as regards to the XPath transform
> specified (as will any use of DSig for the POC) such
> that the XPath for the Envelope is as follows:
> 
>             <Reference URI="">
>                 <Transforms>
>                     <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
>                         <XPath
> xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
>         not(ancestor-or-self::dsig:Signature[@Id=&apos;S1&apos;] or
>             ancestor-or-self::eb:TraceHeaderList)
>                         </XPath>
>                     </Transform>
>                 </Transforms>
>                 <DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>                 <DigestValue></DigestValue>
>             </Reference>
> 
> If use of the Via element for multihop is used, then the XPath would
> need to be:
> 
>             <Reference URI="">
>                 <Transforms>
>                     <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
>                         <XPath
> xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
>         not(ancestor-or-self::dsig:Signature[@Id=&apos;S1&apos;] or
>             ancestor-or-self::eb:TraceHeaderList or
> ancestor-or-self::eb:Via)
>                         </XPath>
>                     </Transform>
>                 </Transforms>
>                 <DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>                 <DigestValue></DigestValue>
>             </Reference>
> 
> The spec will need to be updated to reflect this change (probably the
> latter example so as to capture the multihop use case) for the 1.0 version.
> 
> Cheers,
> 
> Chris
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-poc-request@lists.ebxml.org
> 
>   ----------------------------------------------------------------------------------------------------
>                          Name: ebxmlheadersig.xml
>    ebxmlheadersig.xml    Type: text/xml
>                      Encoding: quoted-printable


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

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC