Re: Decryption Transform comments

Takeshi,

I was thinking of the document which will have a portion signed, but now I'm
thinking this is an application issue, not a Transform issue.

The reason I was thinking this was due to the exclusive canonicalization
issues, and what happens when a portion of XML is signed and then possibly
removed from the document along with the signature, as might occur with XML
protocol applications.

For example if foo:b is to be signed, then later removed from the document
along with the signature:

<a xmlns:foo="http://www.foo.org/">
   <foo:b>
      <EncyptedData>...</EncryptedData>
   </foo:b>
</a>

I understand that the InfoSet includes the namespace declarations
appropriate to b, so the question is when and how to correctly serialize -
it could be the responsibility of the application when it removes the b
element during processing. That is what makes sense to me, so there is no
need to change the recommendation for this

Earlier I was thinking this had to happen during signing (making the
explicit namespace declaration in b). XPath will not necessarily add the
namespace declaration to the b element (at least the processor I tried does
not), so I believe canonicalization would be needed to force the explicit
namespace declaration at b:

   <foo:b xmlns:foo="http://www.foo.org/">
      <EncyptedData>...</EncryptedData>
   </foo:b>

So the transforms would be canonicalize, Xpath and Decryption transform, in
that order.

But if it is up to the application after the signature has been created,
then it is not a transform issue.

---
Frederick Hirsch
Zolera Systems, http://www.zolera.com/
Information Integrity, XML Security