|
From: Ng C. Y. [Cyng] <cy...@cs...> - 2003-04-14 09:40:03
|
Hi Gait,
First of all, I would like to know whether you are using xmlsec
1.0.4 (check-out from Hermes distribution) or 1.05D2 (as downloaded from
Apache).
> 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.
I wonder why there is a digest mismatch if xmlsec 1.0.4 is used.
We are also using 1.0.4 to do signing and the message can be verified
once it is received by MSH.
Can you elaborate your situation? Do you mean "soap-env" which
is hardcoded in SAAJ causes the problem? Or "SOAP" is hardcoded in xmlsec
that causes the problem?
> Another is, which is still open is that the SOAP namespace declarations,
> which occur originally on the SOAP:envelope are moved to the SOAP:Header
> and SOAP:Body elements during C14N. I haven't managed to find or fix that
> yet. Any ideas are welcome...
I have no idea on this now. What is the impact of such a
declaration move? Would it void the signature or digest?
> One more thing, which may be related, is a nullpointer exception that's
> thrown during C14N of an ack from Sun, which has the ds:Reference
> elements for the original message. One of those happens to be
> <ds:Reference xmlns:ds="....." URI="">. C14N throws an exception in
> org\apache\xml\security\c14n\helper\NonNSAttrCompare.java.
> This happens inside the C14N during the sorting of the attributes.
> Tracing revealed that namespace URI and localname resolve to null for
> both attribs, and the exception occurs as the compare is deferred to an
> equals call of the localnames.
I have also been investigating this problem. This occurs in
xmlsec 1.0.5D2 but not 1.0.4. I compare the source trees of 1.0.5D2 and
1.0.4. I find that 1.0.4 somehow comments the sortAttributes() method
in org.apache.xml.security.c14n.helper.C14nHelper.java which calls
the comparator in NonNSAttrCompare.java. But in 1.0.5D2, sortAttributes()
is resumed to work such that for those attributes such as
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature",
the getLocalName() would be null when it is retrieved from
org.w3c.dom.Attr. I wonder if this a bug in 1.0.5D2.
Now, the current situation for signed acknowledgment is as follows.
I have modified packaging (not commited yet) to add <ds:Reference> in
Acknowledgment.java. However, such a message cannot be signed even
with xmlsec 1.0.4 because of other exceptions thrown. I am still
investigating the reason but it's really troublesome.
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
----------------------------------------------------------------------------
|