- From: Takeshi Imamura <IMAMU@jp.ibm.com>
- Date: Mon, 1 Oct 2001 22:23:49 +0900
- To: reagle@w3.org
- Cc: "Hiroshi Maruyama" <MARUYAMA@jp.ibm.com>, "Kento Tamura" <TKENT@jp.ibm.com>, xml-encryption@w3.org
Joseph, >Why we do require this text in any case? What happens if we are signing a >remote object? Shouldn't we instead require it to be a URI in any case (and >even if the base URI is already given in the <Reference URI=""/>. >Otherwise, there is nothing in your processing rules that states how to >combine the URI and Except to identify the approriate element. Right? All the transform has to do is to process a given node-set and does not have to care about whether the node-set is obtained from the same document or an external document. That is the responsibility of the ds:Reference element and hence we think that a fragment identifier is sufficient to identify an appropriate element. >1. There is a GIF. >2. Alice signs the GIF knowing that we will later encrypt it. >3. She encrypts it. >4. She wants the signature to have the transform to indicate it should be >decrypted first. > >How much would the processing model need to change? We need to add >something in step 5 of decrypt? Instead, we should define a new function that decrypts an xenc:EncryptedData element with a type other than Element or Content to an octet stream. Also we have to state that when such an xenc:EncryptedData element is being decrypted, the input to the transform has to be a node-set that has the xenc:EncryptedData element as the first node. >So in step 3, when I want to decrypt the element e in the octets from step >2 (wrapped), I (probably) need to reparse to find e, decrypt the element >(decryption is abstract on input, so I can hand it a node), and decryption >will return "UTF-8 encoded XML character data." (Unless we want to use the >decrypt-and-replace.) Then step 4 requires this to be re-parsed. Step 5 >then removes the root node and dummy elements... It is necessary to use the decrypt-and-replace, otherwise the parsing in Step 4 would not be done correctly. >Could you remind me why we need to do the serialization and dummy node >wrapping again? (We'll need some text for the spec, because if I'm still >getting confused as to why we need to do all these serializations and >parsing others will wonder too!) > >With respect to importation... I suppose I could remove the node e. Decrypt >the node e. Now I have octets representing the UTF-8 encoding of XML >characters. You're saying XPath doesn't tell us how to re-insert this? Yes. So we decided to replace a given node-set totally with another newly created node-set. To do this, the given node-set has to be serialized as a whole, decrypt-and-replaced, and then parsed. Thanks, Takeshi IMAMURA Tokyo Research Laboratory IBM Research imamu@jp.ibm.com
Received on Monday, 1 October 2001 09:23:59 UTC