Mailing-List: contact fx-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (asf.osuosl.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: AW: order of sign and encr in .NET
Date: Fri, 8 Jul 2005 08:42:51 +0200
Message-ID: 
 <A5B453A80186CF47BDA33BBA924EFAE90ACC07@MCHP7I5A.ww002.siemens.net>
Thread-Topic: order of sign and encr in .NET
Thread-Index: AcWDgjaOd8vLKKM7RKOQGYy1WTmHpwABKRrA
From: "Dittmann, Werner" <werner.dittmann@siemens.com>
To: =?iso-8859-1?Q?G=FCrkan_Vural?= <gurkan.vural@tcmb.gov.tr>,
   "Granqvist, Hans" <hgranqvist@verisign.com>
Cc: <fx-dev@ws.apache.org>

G=FCrkan,

to me it seems a problem of BizTalk and/or the .Net WSE
implementation. According to the OASIS WSS specification,
chapter 5:

<quote>
As elements are added to a <wsse:Security> header block,=20
they SHOULD be prepended to the existing elements. As such,=20
the <wsse:Security> header block represents the signing and
encryption steps the message producer took to create the message.=20
This prepending rule ensures that the receiving application can=20
process sub-elements in the order they appear in the=20
<wsse:Security> header block, because there will be no forward=20
dependency among the sub-elements. Note that this specification=20
does not impose any specific order of processing the=20
sub-elements. The receiving application can use whatever order=20
is required.
</quote>

This means, if the receiver sees an encryption sub-element
before a Signature sub-element if processes encryption first.
The ordering of elements is the _only_ information about the
processing sequence. How could the receiver otherweise=20
determine that it should first check Signature, then decrypt?

Maybe you may crosscheck with the MS folks to clarfiy that?
Are there known problems with BizTalk / .Net WSE? In general
we tested interop with .Net WSE.

Regards,
Werner

> -----Urspr=FCngliche Nachricht-----
> Von: G=FCrkan Vural [mailto:gurkan.vural@tcmb.gov.tr]=20
> Gesendet: Freitag, 8. Juli 2005 07:59
> An: Granqvist, Hans
> Cc: fx-dev@ws.apache.org
> Betreff: Re: order of sign and encr in .NET
>=20
>=20
> Granqvist, Hans wrote:
>=20
> >>... biztalk outputs=20
> >>DataReference above Signature element and this causes=20
> >>decryption before signature and sign validation fails because=20
> >>decryption changes the value of body element.
> >>   =20
> >>
> >
> >Is it you or biztalk that implies processing order from
> >the element order?
> >
> >Hans
> > =20
> >
> Whatever order I send data to Biztalk it processes correctly.=20
> Because my
> java client (wss4j) puts the headers of last operation above=20
> the others.
> However Biztalk always sends DataReference above Signature element and
> my java client (wss4j) first processes the encrypted body so signature
> validation fails.
>=20
> --
> gurkan
>=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D-
> Bu e-posta sadece yukarida isimleri belirtilen kisiler=20
> arasinda =F6zel haberlesme amacini tasimaktadir. Size=20
> yanlislikla ulasmissa l=FCtfen g=F6nderen kisiyi bilgilendiriniz=20
> ve mesaji sisteminizden siliniz. Turkiye Cumhuriyet Merkez=20
> Bankasi A.S. bu mesajin icerigi ile ilgili olarak hicbir=20
> hukuksal sorumlulugu kabul etmez.=20
>=20
> This e-mail communication is intended for the private use of=20
> the people named above. If you received this message in=20
> error, please immediately notify the sender and delete it=20
> from your system. The Central Bank of The Republic of Turkey=20
> does not accept legal responsibility for the contents of this message.
>=20