I found the cause of this. I'm building a new signed then encrypted document based on a original payload Document. I first construct a SignedPayload. This document has two wrappers around the actual payload and signature. These wrappers have their own namespace. I construct these nodes using createElementNS. The wrapper elements for the encrypted payload are constructed in the same way.
When encrypting the signed document, the document is canonicalized. In the process the parents of the node being encrypted are scanned for namespaces. The way this is done is to check the attributes of each node for an xmlns attribute. For a Document constructed by calls to createElementNS() and append(), there are no such attributes. The way to overcome the problem is to 1) build the wrappers and append them into a Document 2) run normalizeDocument() on the Document. It's a trap for young players, I suppose. Is this the way things ought to be, or should the canonicalization be checking the namespace and prefix components on each element, and including an xmlns attribute when any change occurs between an element and its parent? Peter B. West wrote: > > I've encountered a strange problem in the process of decrypting a message > which had been signed using xml:dsig before being encrypted with > xml-security. > > The elements wrapping both the signed message and the encrypted message > were defined in the same namespace, and given the same prefix: "sp" in > this case. For example, the signed payload was wrapped in an element like > <sp:SignedPayload > xmlns:sp="urn:xml-gov-au:nehta:types:SecuredPayload:1.0"> > > When encrypted, the encrypted payload was wrapped in an element like > <sp:EncryptedPayload > xmlns:sp="urn:xml-gov-au:nehta:types:SecuredPayload:1.0"> > > When I tested the sign-encrypt/decrypt-verify cycle within a Java-only > environment, featuring a glassfish V2UR2 server, the process worked. That > is, I could sign then encrypt a payload, place that in a web services > message (with its own levels of signing and encryption), send that to a > glassfish server, where the payload was stored, then retrieve the payload > in another WS message. > > However, when I sent the original message to a WCF server, and it was > retrieved using WCF and .NET, the decryption failed. Rather, the > decryption was successful, but resulted in an XML fragment with an unbound > "sp:" prefix. Sure enough, the xmlns:sp declaration was missing. > > To isolate this, I changed the SignedPayload namespace and prefix. > <sip:SignedPayload > xmlns:sip="urn:xml-gov-au:nehta:types:SignedPayload:1.0"> > > This then gave the same failure on a Java environment. I tested it without > the web services stage by a simple direct sign-encrypt/decrypt-verify > cycle, and the decrypt threw an exception complaining about the unbound > prefix "sip:". I suspect that in the first instance, the profix was being > resolved by climbing the tree enclosing the decrypted looking for an > xmlns:sp, and finding it on the element enclosing the encrypted payload. > > Has this behaviour been seen before? > > -- View this message in context: http://www.nabble.com/Unbound-prefix-after-decryption-tp19626544p19659756.html Sent from the Apache XML - Security - Dev mailing list archive at Nabble.com.
