>>> 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.comReceived on Friday, 3 May 2002 04:34:00 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:21 GMT