Re: decrypt transform processing rules

Hi Ari,

r/arik@phaos.com/2002.09.24/19:36:37
>Dear All,
>
>It seems to me that it should be possible to eliminate the canonicalization
>and re-parsing of the result node-set in the decryptXML(N,E) function as
>described in [1]. Since the decryptNodeSet(N,E) function already mandates
>serialize/wrap/parse/unwrap for each replacement node-set, why not perform
>the namespace and inherited "xml:" attribute augmentations at that point?
>Then decryptXML(N,E) could simply replace the EncryptedData elements with
>their corresponding replacement node-sets and return the result node-set.

The decryption transform can't actually modify the input
document; it must return a copy. The easiest way to do this
is c14n/parse.  An implementer is free to actually do this
by just copying the input node set (or modifying it, if it is
known that it is a transient node set) as long as the result
is the same as if c14n/parse happened.

C14n/parse is particularly redundant if the input node set is
a single EncryptedData element. In this case, optimizations
are possible, but they can be done without changing the spec.

>Since the XML Signature reference processing rules will end up applying C14N
>to the node-set anyway if needed, the extra serialization and re-parsing at
>the end of the decrypt transform would seem to be a waste. Is there another
>desirable effect of this canonicalization that I'm not seeing?

We can't modify the input node set; the purpose of the
c14n/parse step is to effect a replacement operation on a
copy of the input node set.

Also, implementations are free to implement
c14n-with-replacement to output canonical form (it is
technically possible) and then to omit the parse step if
they observe that the following operation is c14n; as long
as there is no observable difference in the output.

I've not looked at your questions or my answers in depth;
apologies if I'm way off the mark.

merlin

>[1]
>http://www.w3.org/Encryption/2001/Drafts/xmlenc-decrypt.html#sec-xml-process
>ing
>
>Ari Kermaier
>
>

Received on Thursday, 26 September 2002 11:00:46 UTC