santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter B. West" <li...@pbw.id.au>
Subject Unbound prefix after decryption
Date Tue, 23 Sep 2008 12:26:05 GMT

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-tp19626544p19626544.html
Sent from the Apache XML - Security - Dev mailing list archive at Nabble.com.


Mime
View raw message