Re: [ebxmlms-develop] troubles with signed acks (still)

[Gait B. <gai...@ti...>]

Hi NG,

I would still strongly propose to pass the message to xmlsec as a string,
simply to avoid issues with JAXM and dom4j. In fact, for received messages I
believe it's the only way. both JAXM and Axis do 'something' that renders
the received message different from the one passed to xmlsec. For
verification, you must pass in the received data as is to have any chance of
succesful verification. It's not a big deal to plug in a call to
getContent() and rewrapping xml sec to support string based verification,
and will solve at least that part of the problem.
But even for outgoing messages, I'd still propose to first render the
message and then pass it on to xmlsec for signing. If not, you need to be
sure that whatever is passed to xmlsec is identical to what's sent out on
the wire, otherwise the hash will mismatch and verification is bound to fail
again.

just my EUR 0.02.

--Gait.

----- Original Message ----- 
From: "Ng Chi Yuen [Cyng]" <cy...@cs...>
To: <ebx...@li...>
Sent: Monday, May 05, 2003 5:47 AM
Subject: RE: [ebxmlms-develop] troubles with signed acks (still)


> Hello,
>
> > > one issue is with the soap namespace prefix. I've nailed this down to
the
> > > fact that hermes passes the doc to xmlsec as a DOM tree, rather than
as a
> > > string. When passing this to xmlsec, reserialization uses SAAJ, which
> > > hardcodes 'soap-env' as the prefix, while the others use SOAP. this
> > > causes a digest mismatch. I've solved this (for now) by swapping to
SOAP
> > > as the prefix in SAAJ and Hermes, but we need to change this so that
the
> > > actual streamed data is passed to XMLSignature in xmlsec.
>
> > Our business partner's incoming messages are not being validated, and
I'm
> > wondering if it's because they use "SOAP-ENV" as a prefix. I'll try
> > hacking Hermes to use "SOAP-ENV" as well.
>
>
>         Let me summarize the findings on xmlsec, JAXM and Axis so far.
>
> JAXM with xmlsec:
>     - Hermes sends signed message : the signed message should be correct
>       *if* xmlsec's algorithms such as digest, canonicalization are
>       implemented correctly, i.e., it should be verified by non-Hermes
>       MSH. The reasons why I say so are that: (1) JAXM uses "soap-env" as
>       the SOAP envelope prefix no matter what is set in
>       NAMESPACE_PREFIX_SOAP_ENVELOPE. After the transformation from JAXM
>       tree (dom4j) to DOM tree, every element nodes and text nodes should
>       be preserved (I ever examined) such that xmlsec should sign the
>       correct message as I also followed exactly the signing example.
>       (2) After signing, Signature element from DOM tree is re-inserted
back
>       to JAXM tree. I examined the serialization of JAXM tree should look
>       the same as the DOM tree after canonicalization. So I expect the
signed
>       message can be verified by non-Hermes MSH.
>
>     - Hermes receives signed message : If the received signed message is
>       generated by Hermes, that's ok for sure. Otherwise, problems happen.
>       If the signed message, say, has "SOAP-ENV" as envelope prefix, JAXM
>       always represents this as "soap-env" internally. No matter the JAXM
>       tree is transformed or printed out as String, the message changes to
>       use "soap-env" prefix so that verification must fail. Currently, I
>       have no idea to patch anything at all. The conclusion seems to be
that
>       JAXM with xmlsec fails to verify non-Hermes messages.
>
> Axis with xmlsec:
>     - Hermes sends signed message : everything is preserved after
>       transformation from Axis tree to DOM, and after re-insertion of
>       Signature from DOM to Axis tree, i.e., the siging process should be
>       correct. However, when the message is serialized by calling
writeTo()
>       finally, the Axis tree is beautified by adding extra "\n" and spaces
>       which obviously voids the signature. Currently, I don't know how to
>       disable the Axis setPretty() function. I ever asked in Axis mailing
>       list and it seems that some tricky ways of calling
org.apache.xxx.xxx
>       should be called to control the formatting but my feeling is that
this
>       will be very implementation dependent and one is not calling the
>       standard JAXM interface. (I ever find other bugs in Axis that I will
have
>       to report soon.) Another idea is to serialize the unsigned the
message
>       first as String and then sign this String. Hopefully, after signing,
>       the serialization stream may look identical before signing. I
haven't
>       tested this but this is quite hacked as well in my personal view.
>
>     - Hermes receives signed message : For non-Hermes signed message, the
>       Axis tree preserves all namepsace prefixes no matter for SOAP
envelope
>       or Signature, i.e., it seems ok for you to use "SOAP-ENV" or "dsig".
>       I use your dumped sample and certificate to test. Sigh.... digest
>       verification for URI="" and URI="xxx" is ok while the signature
values
>       fails. I don't know why yet.
>
>
>         You see. Really "good" enough to use and investigate these kinds
of
> libraries. I am very sorry that this causes problems to your testing or
> productions cases. But the way is really hard. Currently, I just focus on
> Axis and I just hope one solution works first.
>
> Regards,
> CY
>
> --------------------------------------------------------------------------
--
> Ng Chi Yuen, CY.       cy...@ce...       http://www.cecid.hku.hk/
> Technology Officer,
> Centre for E-Commerce Infrastructure Development,
> The University of Hong Kong
> --------------------------------------------------------------------------
--
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> ebxmlms-develop mailing list
> ebx...@li...
> https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop