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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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


Subject: [ebxml-msg] Ebxml Messaging Digital Signature requirements


As I mentioned, I am hoping to provide wss some information about the
requirements that shaped the ebxml solution for xmldsig. I do not want
to send them the specific construct we used, but instead lay out the
requirements that shaped our choice of an enveloped signature using the
xpath filter we selected.

Here is a statement of background and requirements I came up with. 

If you can see ways to sharpen up this requirement statement, please let
me and/or the list know, and I will roll them in before I send off to
the wss wizards.

=============

Given that SOAP allows intermediaries to add elements at least to the
SOAP:Header EII (element information item)and given SOAP requires
intermediaries to remove targeted modules/header blocks in accordance
with SOAP processing semantics, ebXML wanted to make certain that the
ultimate SOAP node only received what the initial soap node had targeted
to the ultimate node, and not anything intermediaries targeted to the
ultimate node. In addition,

ebXML messaging wanted an XMLDsig signature such that:

1.	Signing is over a multipart/related, where there is a
SOAP:envelope in the first bodypart, and some XML (or even nonXML) in
some other bodypart. While more than one bodypart is permitted,
signatures may be over the first part and any selection of the other
bodyparts. [CID URI resolvers are added for this.]
2.	SOAP header blocks targeted to intermediaries are not to be
included in the original signature.
3.	The original SOAP signatures are signed over. Other SOAP
signatures may be added, and the original signature must not break.
4.	Any addition to an originally signed over bodypart [other than a
signature or a routing record] must be detectable in the sense that the
signature will not verify.
5.	Any deletion from the original bodyparts, other than targeted
header blocks for intermediaries, must break the signature.
6.	Any addition of ultimate soap node header blocks by
intermediaries must break the signature.




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


Powered by eList eXpress LLC