- From: merlin <merlin@baltimore.ie>
- Date: Thu, 02 May 2002 16:27:27 +0100
- To: Ari Kermaier <arik@phaos.com>
- Cc: reagle@w3.org, "Takeshi Imamura" <IMAMU@jp.ibm.com>, "Hiroshi Maruyama" <MARUYAMA@jp.ibm.com>, xml-encryption@w3.org
r/arik@phaos.com/2002.05.01/19:56:54 >If this is correct, my proposed text in [2] for decryptXML(X, e, C) and >decryptOctets(X, e) would be OK. Am I missing anything? > >[1] http://lists.w3.org/Archives/Public/xml-encryption/2002Apr/0119.html >[2] http://lists.w3.org/Archives/Public/xml-encryption/2002May/0002.html Hi Ari, My question would mirror Joseph's: What does it mean to replace an element node with an octet stream? It would be necessary to state something along the lines of: 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]. 2. Convert X to an octet stream as described in The Reference Processing Model (section 4.3.3.2) of the XML Signature specification [XML-Signature], but in place of e and its descendants, insert the octet stream obtained in step 1. 3. Wrap the resulting octet stream in the context of C as specified in Text Wrapping (Appendix A). 4. Parse the wrapped octet stream as described in The Reference Processing Model (section 4.3.3.2) of the XML Signature specification [XML-Signature], resulting in a node-set. 5. Y is the node-set obtained by removing the root node, the wrapping element node, and its associated set of attribute and namespace nodes from the node-set obtained in Step 4. 6. Return Y. Merlin ----------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. This footnote confirms that this email message has been swept for Content Security threats, including computer viruses. http://www.baltimore.com
Received on Thursday, 2 May 2002 11:27:37 UTC