<param name="action" Value="Signature Encrypt"/>
<Header>
<Security>
<Encrypted key> ... </Encrypted key>
<Signature> digest of the element body </Signature>
</Header>
<body>
...encrypted data...
</body>
Problem! People may guess what is the orignial body element, calculate its digest and compare to this one (in the <signature> element).
On the other hand:
<param name="action" Value="Encrypt Signature"/>
<Header>
<Security>
<Signature> digest of the encrypted element body </Signature>
<Encrypted key> ... </Encrypted key>
</Header>
<body>
...encrypted data...
</body>
People may trry to guess the original body elment and encrypt it ant then calucalte its digest.
However, during encryption a ramdon element is introduced, so the result encryptions will be different,
so this won't work.
Therefore for higher security first encrypt and then sign: -> <param name="action" Value="Encrypt Signature"/>
Hope this helps someone.
José Ferreiro
On 8/31/06, Xinjun Chen <[EMAIL PROTECTED]> wrote:
Hi Werner,
Is it possible to attach the order information as policy? Then the
order of the received headers will not really matter. Right? I am
sorry that I don't yet know how to do that. I mean how to attach
security policy. Could you provide some examples or pointers to those
examples?
Regards,
Xinjun
On 8/17/06, Dittmann, Werner <[EMAIL PROTECTED]> wrote:
> Hello,
>
> wlle, that depends what you like to do: as I understand
> it then you would like to encrypt and sign an element (the
> same element). here you have to options:
>
> - sign the clear data, then encrypt. This is what you describe
> as your fist ordering.
> or
> - encrypt first, then sign the encrypted data. IMHO this is
> what you describe as the second ordering
>
> The first option signs the encrypted data, any modification on
> the encrypted data will be detected. The receiver has to verify the
> Signature over the encrypted data. For the second option you
> have to decrypt first, then you can verify the signature.
>
> The ordering of the security headers reflects these dependencies.
> As for WSS4J 1.x this ordering is required because WSS4J 1.x
> performs the security methods in the same order as they apear
> in the header.
>
> Regards,
> Werner
>
> > -----Ursprüngliche Nachricht-----
> > Von: Long, Hai [mailto:[EMAIL PROTECTED]]
> > Gesendet: Mittwoch, 16. August 2006 16:58
> > An: [email protected]
> > Betreff: WS security header order problem
> >
> > Hello,
> >
> > I have a problem about the security header order. In the OASIS is
> > recommended that if Sign Encryption is used, the order in WS header
> > should looks like
> > 1. Order (Sign+Encyption)
> > <wsse:Security> header
> > [encryption element]
> > [signature element]
> >
> > If the Encryption Sign is used, the order should be
> > 2. Order (Encryption+Sign)
> > <wsse:Security> header
> > [signature element]
> > [encryption element]
> >
> > But this is just one recommendation but a muss in the spec. How can I
> > deal with Sing+Encrypted message but with second order in the
> > Header. Is
> > it possible to communicate this kind of application with WSS4J? I get
> > always validation problem, since the wss4j try to validate it before
> > decrypt the message at first.
> >
> > Thanks for Help.
> >
> > Regards,
> > Hai
> >
> > ---------------------------------------------------------------------
> > 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
José Ferreiro
EPFL Communication Systems engineer
ing.sys.com.dipl.EPFL
Phone: +41 (0)79 644 98 25 [+41 (0)76 526 55 55]
