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

[Ng C. Y. [Cyng] <cy...@cs...>]

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
----------------------------------------------------------------------------