[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC