W3C home > Mailing lists > Public > xml-encryption@w3.org > May 2002

Re: Decryption Transform processing question

From: Takeshi Imamura <IMAMU@jp.ibm.com>
Date: Fri, 3 May 2002 17:23:38 +0900
To: merlin <merlin@baltimore.ie>
Cc: xml-encryption@w3.org
Message-ID: <OFB1D6F312.941B662E-ON49256BAE.002D2369@LocalDomain>

>>>   1. Decrypt the element corresponding to e (which may require
>>>serializing and reparsing if the node set does not contain the entire
>>>subtree rooted at e). The result is an octet stream corresponding to
>>>UTF-8 serialized XML data, as specified in the XML Encryption
>>>specification [XML-Encryption].
>>Why would it be necessary to serialize and reparse if e's children were
>>in X? Since X is a set of nodes in a document tree, the normal XML
>>decryption processing should be able to locate e's children as needed. In
>>fact serializing X would mean that any nodes not originally in X would be
>>completely inaccessible from within the document obtained by re-parsing
>>serialization. (Actually, this is another good argument for doing away
>>the current Step 1, which applies C14N to X.)
>The serialization is necessary for bizarre node sets that cut out
>parts of an EncryptedData, but that just introduces a whole bunch
>of problems. It is probably easiest and best for many reasons if
>we decrypt the element e, regardless of what children are present
>in the node set. So:

I'm not confident of this.  Maybe we should ask the XPath WG if, in this
case, it is correct to access nodes that are not in a node-set.

>1. Decrypt the element corresponding to e (without regard to
>which of its descendants are present in X). The result is an octet
>stream corresponding to UTF-8 serialized XML data, as specified
>in the XML Encryption specification [XML-Encryption].

Tokyo Research Laboratory
IBM Research
Received on Friday, 3 May 2002 04:34:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:09 UTC