[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='S1'] 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='S1'] 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]
Powered by eList eXpress LLC