If your question is already answered then disregard this. I think the intention of the confirmation element is to confirm that all elements in the message actually received where signed as the sender intended.
They use SignatureValue as correlation, which is fine, this value should be unique (it is an encrypted hash algorithm after all). The real possibility of overlap would be a duplicate signature, signing the exact same elements, and in this instance confirmation doesn't have to be done on both, since they are the same. Algorithmically, this can be done by simply storing all sent signature values sent in a set, and upon receiving the confirmation, verify that all entries in the set have a corresponding confirmation. You shouldn't need to care about order or duplicates. -Jason > -----Original Message----- > From: Davanum Srinivas [mailto:[EMAIL PROTECTED] > Sent: Friday, July 15, 2005 11:39 AM > To: [email protected]; Granqvist, Hans > Cc: [EMAIL PROTECTED] > Subject: Re: SignatureConfirmation > > Hans, > Could you please help with some info on updating to WSS 1.1? > > Werner, > i've checked in the latest docs in the specs directory. > > thanks, > dims > > On 5/6/05, Werner Dittmann <[EMAIL PROTECTED]> wrote: > > Dims, > > > > I started to dig into the SignatureConfirmation stuff. As usual some > > points are not > > clear to me, also after looking into the examples of the interop docs > > you sent me. > > > > Maybe you can forward the question the the WSS group. > > > > In the SOAP Message security document, dated Feb, 14th the relevant part > for > > the SignatureConfirmation reads in section "response generation rules": > > > > <quote> > > every response message generated, the responder MUST include a > > <wsse11:SignatureConfirmation> element for every <ds:Signature> element > it > > processed from the original request message. The Value attribute MUST be > > set to the exact > > value of the <ds:SignatureValue> element of the corresponding > > <ds:Signature> element. > > </quote> > > > > If the request contains just _one_ ds:Signature then it is easy, but how > > is the > > correlation done if the request contains more than one ds:Signature? The > > responder > > can insert the the SignatureConfirmation elements for each ds:Signature > > it sees. > > But how does the the initiator (receiver of the response) now correlates > > both? > > > > I don't see any Id mechanism in the spec that supports such a > correlation on > > the initiator side. Or is the correlation done implicitly via the order > > of ds:Signature > > in the request, i.e. the responder must insert SignatureConfirmation in > > the same > > order as it processed the ds:Signature? IMHO this would be complicated > > to implement > > and is inherently unsafe. Another way could be that the initiator loops > > over all > > SignatureConfirmation and checks if it generated a corresponding > > ds:Signature - well, > > IMHO not a good way either. > > > > Also the interop docs you sent me didn't help a lot (at least not for > > me). Looking at the > > example response message in chapter 3.3 I just see the > > SignatureConfirmation element, > > but not how it directly relates to the security request message shown in > > chapter 3.2 except > > for the fact that the request contains one ds:Signature only. > > > > BTW, the examples themselves are somewhat confusing as they use the same > > SignatureValues for both the request and the response - this is > > confusing at the > > first look because this _should_ never happen. I know, its just an > > example, but .... > > > > Regards, > > Werner > > > > Davanum Srinivas schrieb: > > > > >Sounds tough...Here is the interop doc. It's basically > > >SecureConversation + ReliableMessaging. > > > > > >thanks, > > >-- dims > > > > > >On 4/12/05, Dittmann Werner <[EMAIL PROTECTED]> wrote: > > > > > > > > >>Dims, > > >> > > >>just looked at the specs (was the first time I saw it because > > >>I don't check the OASIS WS site regularly). > > >> > > >>Unfortunatly it's not so easy to implement it to conform to > > >>the specs. > > >> > > >>Reasons: > > >> > > >>WSS4J needs to correlate the request and the response data > > >>on both sides (sender and receiver). To do that we need to > > >>introduce some handshake data in the message context(probably > > >>using a property) of the Axis message. > > >> > > >>Both parts of the handler (the receiver and the sender) must > > >>be extended to support this. Also the WSS4J library code > > >>must be extended. Currently neither the WSSecurityEngine nor > > >>the Signature generating parts of WSS4J (WSSigneEnvelope) deal > > >>in an way with the Signature value directly. > > >> > > >>To conform to the specs we need to get this value and store > > >>it in the "handshake" data. This must be done when generating > > >>a Signature (sending a request) and during Verification > > >>(receiving a request). Thus WSSecurityEnging and WSSignEnvelope > > >>must be enhanced to return the Signature value to the handler. > > >> > > >>When generating the response the handler must retrieve the > > >>handshake data (Signature Value) gathered during verification > > >>and insert it into the response signature to be generated. This > > >>is an additional enhancement of WSSignEnvelope. > > >> > > >>We need to enhance the receivier part of the handler to cope > > >>with the required checks. The receiver must get the > > >>SignatureConfirmation data from the resopnse and compare it with > > >>the Signature value generated during request signing. This requires > > >>an enhancement of the handler as well as of WSSecurityEngine to > > >>get the new SignatureConfirmation element and return it to the > handler. > > >> > > >>Then we need to extend the handler to accept new control > > >>parameters to drive the SignatureConfirmation behaviour. > > >> > > >>Well, if time permits I may be able to start an implementation > > >>during the next weekend - currently I'm on a business trip. > > >>Are there any interop specs available? > > >> > > >>Regards, > > >>Werner > > >> > > >> > > >> > > >>>-----Ursprüngliche Nachricht----- > > >>>Von: Davanum Srinivas [mailto:[EMAIL PROTECTED] > > >>>Gesendet: Dienstag, 12. April 2005 04:44 > > >>>An: Dittmann Werner; Werner Dittmann > > >>>Betreff: SignatureConfirmation > > >>> > > >>> > > >>>Werner, > > >>> > > >>>Do you think it is easy to add SignatureConfirmation (as mentioned in > > >>>this OASIS WS-Security 1.1 draft). We (Apache) are trying to go to an > > >>>Interop workshop for SecureConversation + ReliableMessaging and folks > > >>>there are pushing us to implement this thingy. unfortunately there is > > >>>VERY little time. Interop is on 13,14,15th :( > > >>> > > >>>Please see enclosed PDF and the links below. > > >>> > > >>>Thanks, > > >>>-- dims > > >>> > > >>>http://lists.oasis-open.org/archives/wss/200408/msg00059.html > > >>>http://lists.oasis-open.org/archives/wss/200408/doc00002.doc > > >>>-- > > >>>Davanum Srinivas - http://webservices.apache.org/~dims/ > > >>> > > >>> > > >>> > > > > > > > > > > > > > > > > > > > -- > Davanum Srinivas -http://blogs.cocoondev.org/dims/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
