Re: Encryption: Decryption Transform for XML Signature

On Thursday 20 September 2001 12:45 pm, Takeshi Imamura wrote:
> If we define a new element like Except, we'd like to change the URI
> attribute to Idref or something like that.  If we do so, the following
>
> restriction on the value of the attribute is not necessary:
> >The value of the URI attribute of the enc:DataReference element
> >MUST be a non-empty same-document URI reference [URI]
> >(i.e., a number sign ('#') character followed by a fragment identifier)
> >and identify an enc:EncryptedData element.

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?

> Sorry, I was wrong.  X may not be a whole document because X can be
> filtered by the previous transform.

Ok.

> >> I'm sorry, but this sentence may be a little confusing.  Our question
> >> is whether this transform should support types other than Element or
> >> Content, such as image/gif.  In that case, we have to change the
> >> processing rules.
> >
> >What is the scenario? Even if you have an image/gif in the XML, it will
> > be encoded and will likely be available as Element Content ...?
>
> Suppose a scenario where Alice signs an external image/gif, but she also
> knows that the image/gif will be encrypted to an EncryptedData element,
> and so adds the decryption transform.  The current processing rules don't
> fit the scenario.

Ahh...

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?


> >How is this wrapping performed? (This is also related to my confusion
>
> about
>
> >steps 1/4 of serialization/parsing). Since it's octets, I presume one is
> >pre/post-pending the octet representations of UTF-8 encoded characters
> > of the document type declaration and dummy elements?
>
> Yes, you're right.

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

> >Why can't we do this? (Is this a limit of Encryption or DOM?) I'm not
> >concerned about the creation of the new node-set Y, but of the
> >serialization/parsing. Particularly the serialization as we already know
> >c14n is a very expensive process and we will have to do this for every e
>
> Because an XPath node-set consists of nodes in a document and does not
> have any concept to import nodes from other documents.  

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? 
(Would encryption's decrypt-and-replace help?)

> As for
> serialization, C14N isn't required because a parsing context is always
> added.

Ok.

Received on Thursday, 27 September 2001 18:39:57 UTC