- 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
>>> 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 not >>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 the >>serialization. (Actually, this is another good argument for doing away with >>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]. Thanks, Takeshi IMAMURA Tokyo Research Laboratory IBM Research imamu@jp.ibm.com
Received on Friday, 3 May 2002 04:34:00 UTC