W3C home > Mailing lists > Public > xml-encryption@w3.org > October 2001

Re: Encryption: Decryption Transform for XML Signature

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
Message-ID: <OFAC27AB9D.BB53621F-ON49256AD8.003F7B33@LocalDomain>


>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
>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.
>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.

Tokyo Research Laboratory
IBM Research
Received on Monday, 1 October 2001 09:23:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:19 GMT