[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-msg] ds:Signature Algorithm
This suggests that maybe we *do* need an enclosing element on the Signature ala SOAP-SEC [1] and now WS-Security [2] that would allow for an actor attribute and possibly a mustUnderstand. It also might allow for us to explicitly identify which signature element signs the message, distinguishing it from others that may be applied for other purposes such as signing of SAML assertions, etc. Chris PEDRETTI,BRUCE (HP-NewJersey,ex2) wrote: > It may not be necessary to require IMs to Ack separately. The transform we > currently allow excludes the nodes the IMs may modify in transit. These > excluded nodes could have their own separate signature that signs only those > things the IMs need modify (Via, Acknowledgement). (The signature > information must be enveloped by they element it signs.) This way, the > intermediate signature can be "peeled away" with out affecting any > end-to-end signed information. Further, IMs may have the confidence they > require in the information they are acting upon. Allowing this separate > signature should not effect anything else. > > ============================================ > Bruce Pedretti Hewlett-Packard Company > Software Developer 6000 Irwin Road > (856) 638-6060 Mt. Laurel, NJ 08054 > http://www.hp.com/ > ============================================ > > -----Original Message----- > From: David Fischer [mailto:david@drummondgroup.com] > Sent: Tuesday, October 30, 2001 10:21 AM > To: ebXML Msg > Subject: RE: [ebxml-msg] ds:Signature Algorithm > > > I think we need to allow for signing an IM Acknowledgment. Since we have > decided to exclude anything with Actor=Next or Actor=NextMSH, we need to > specify > that signed IM Acks MUST be sent by themselves (not attached to another > message) > and that they not use the Actor Transform. > > What does this mean when it is the End who is sending the signed IM Ack back > to > the previous hop. The connection can still stay open for another response > (syncReply) but I think the signed Ack needs to back alone. > > Regards, > > David Fischer > Drummond Group. > > -----Original Message----- > From: David Fischer [mailto:david@drummondgroup.com] > Sent: Friday, October 26, 2001 3:54 PM > To: PEDRETTI,BRUCE (HP-NewJersey,ex2) > Subject: RE: [ebxml-msg] ds:Signature Algorithm > > > This is Chris' idea and we decided to accept it on the Oct 15 conference > call. > I just got a message from Arvola about the same concern. > > We have always excluded Via and AckRequested from the Signature, so that has > not > changed. We now have excluded Intermediate Acknowledgments. I suppose that > for > signed IM Acks sent by themselves, we could leave that part of the Transform > off > (have a special section in Multihop for signing IM Acks). We are discussing > putting these with the "HTTP 200 OK" anyway, so sending them by themselves > might > be the default. The other alternative is to sign just the IM Acks, but > don't we > need to tie the Ack to the MessageHeader to be meaningful? > > I am not sure what the answer is yet. . . > > Regards, > > David Fischer > Drummond Group. > > -----Original Message----- > From: PEDRETTI,BRUCE (HP-NewJersey,ex2) [mailto:bruce_pedretti@hp.com] > Sent: Friday, October 26, 2001 3:07 PM > To: 'David Fischer' > Subject: RE: [ebxml-msg] ds:Signature Algorithm > > > David, > > Do I understand you proposal correctly: you suggesting that the we forbid > the signing of any element with a soap:actor element where the attribute > value is one of the URLs you supply below? > > If yes, is there ever a circumstance when the nextMSH actor nodes would > desire a signature for verification of their particular instructions? Or > are other security measures to be taken to trust the information in, say, a > Via element (which can provide foreign namespace attributes which might > contain some kind of instructions). > > I wonder if we may need to allow enveloped signatures inside elements like > Via (where the signature is only allowed to sign the Via element thereby > keeping other signed data intact). An MSH that changes a Via (or any > actor=nextMSH) node would be responsible for signing the content anew (or > removing the signature of the previous MSH). > > b > > ============================================ > Bruce Pedretti Hewlett-Packard Company > Software Developer 6000 Irwin Road > (856) 638-6060 Mt. Laurel, NJ 08054 > http://www.hp.com/ > ============================================ > > -----Original Message----- > From: David Fischer [mailto:david@drummondgroup.com] > Sent: Wednesday, October 24, 2001 3:44 PM > To: ebXML Msg > Subject: RE: [ebxml-msg] ds:Signature Algorithm > > > OK, I have some more information and I am thinking we should stick to the > enveloped-signature algorithm. > > Apparently, the use of peer signatures is not well-defined in the security > industry anyway. So we really don't need to worry about this. > > For nested signatures, it looks like you can take the older signature(s) and > put > it(them) into a Signature+Object (wrap another ds:Signature element around > the > first ds:Signature element). > > I will amend my proposal to: > > <Signature xmlns=". . ."> > <SignedInfo> > . . . > <Reference URI=""> > <Transforms> > <Transform > Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> > <Transform Algorithm=". . ."> > <XPath> not(ancestor-or-self::*[@soap:actor= > > "http://www.oasis-open.org/committees/ebxml-msg/nextMSH"] | > ancestor-or-self::*[@soap:actor= > "http://schemas.xmlsoap.org/soap/actor/next" ] > ) > </XPath> > </Transform> > </Transforms> > </Reference> > </SignedInfo> > </Signature> > > Will this work? Anyone have an opinion? > > Regards, > > David Fischer > Drummond Group. > > -----Original Message----- > From: David Fischer [mailto:david@drummondgroup.com] > Sent: Wednesday, October 24, 2001 12:42 PM > To: Christopher Ferris > Cc: Doug Bunting; ebXML Msg > Subject: RE: [ebxml-msg] ds:Signature Algorithm > > > Well, we did, Chris. > > Did you also forget that you were supposed to provide a Transform XPath to > exclude all actor=next? > > What do you think of mine? Will it work? > > David. > > -----Original Message----- > From: Christopher Ferris [mailto:chris.ferris@sun.com] > Sent: Wednesday, October 24, 2001 10:58 AM > To: David Fischer > Cc: Doug Bunting; ebXML Msg > Subject: Re: [ebxml-msg] ds:Signature Algorithm > > > I don't recall a decision to exclude all Signatures. > > Cheers, > > Chris > > David Fischer wrote: > > >>Yes, I know, there are good cases for both separate signatures and for >> > signing > >>over previous signatures. >> >>We decided to exclude all signatures two con calls ago when we could not >> > figure > >>out how to add a signature without breaking a previous signature (how do >> > you > >>know which signature to process first and then you must exclude the later >>signatures when processing the earlier ones). We decided NOT to discuss, >> > in > the > >>spec, the use of multiple signatures. >> >>As with all things in this group, nothing is final ;-^. >> >>Regards, >> >>David Fischer >>Drummond Group. >> >>-----Original Message----- >>From: Doug Bunting [mailto:dougb62@yahoo.com] >>Sent: Tuesday, October 23, 2001 5:17 PM >>To: ebXML Msg >>Subject: Re: [ebxml-msg] ds:Signature Algorithm >> >> >>David, >> >>Are we really deciding to exclude ALL signature elements? I can see some >>very good use cases (validating someone else's signature for example) for >>signing a previous signature. >> >>Separately, when was that decision made? >> >>thanx, >> doug >> >>----- Original Message ----- >>From: "David Fischer" <david@drummondgroup.com> >>To: "Christopher Ferris (E-mail)" <chris.ferris@east.sun.com> >>Cc: "ebXML Msg" <ebxml-msg@lists.oasis-open.org> >>Sent: Tuesday, 23 October 2001 15:04 >>Subject: [ebxml-msg] ds:Signature Algorithm >> >> >>Chris, >> >>Since we are deciding to exclude ALL signature elements, shouldn't we get >>rid of the >>http://www.w3.org/2000/09/xmldsig#enveloped-signature algorithm and just >>use: >> >> <XPath> not(ancestor-or-self::ds:Signature) </XPath> >> >>which would exclude ALL ds:Signature elements? Or better yet: >> >> <XPath> not(ancestor-or-self::ds:Signature | >>ancestor-or-self::*[@soap:actor="http://oasis-open.org/committees/ >>ebxml-msg/nextMSH"] | >>ancestor-or-self::*[@soap:actor="http://schemas.xmlsoap.org/soap >>/actor/next" ] ) >></XPath> >> >>Regards, >> >>David Fischer >>Drummond Group. >> >> >>---------------------------------------------------------------- >>To subscribe or unsubscribe from this elist use the subscription >>manager: <http://lists.oasis-open.org/ob/adm.pl> >> >> >>---------------------------------------------------------------- >>To subscribe or unsubscribe from this elist use the subscription >>manager: <http://lists.oasis-open.org/ob/adm.pl> >> >> >>---------------------------------------------------------------- >>To subscribe or unsubscribe from this elist use the subscription >>manager: <http://lists.oasis-open.org/ob/adm.pl> >> > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC