Re: Encryption: Decryption Transform for XML Signature

[Resulting document:
  http://www.w3.org/Encryption/2001/Drafts/xmlenc-decrypt.html 
  $Revision: 1.5 $ on $Date: 2001/09/18 18:56:29 $
]

On Tuesday 18 September 2001 02:32, Takeshi Imamura wrote:
> We don't persist in the use of the element, and if you and others think
> so, we can change it to another.

I've changed it to Except (and use the algorithm identifier URI as the 
namespace for the element), and I'm much happier with that now that I think 
about it, if others aren't, please say so. The example now looks like:

   [04]     <Reference URI="#order">
   [05]       <Transforms>
   [06]         <Transform Algorithm="http://www.w3.org/2001/04/decrypt#">
   [07]           <Except URI="#enc1" 
                     xmlns="http://www.w3.org/2001/04/decrypt#"/>

> Agree.  Could you move the definition of noDecryptNodes() before that of
> decrypt()?

OK.

> >Also, is X in either function always the whole document, or can it be
> > some subset?
>
> X is always the whole document.

[Definition: Let X be a node-set representation /+of an XML document. +/
Let e be the first element node in X. A parsing context of X consists of 
the following items: ...

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

> >1. Apply noDecryptNodes(X, R)
> >1.1 The node e = <EncryptedData Id="enc2" /> is not in R, so we pass.
> >1.2 The node e = <EncryptedData Id="enc2" />  is in R, so we decrypt(X,
> > e, C)
> >1.2.1 X is canoncalized into octets according to Canonical XML. (Do
> > these processing rules permit any other serialization?)
>
> Yes, because the octets will be wrapped with a parsing context at the
> next step anyway.

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? Also, when I do the 
actual decryption, I'm finding the offset into the octets and processing 
that data, right? Or are you re-parsing it (or finding the SAX event) to 
find the actual CipherData?

> >So I'm sure there's a reason I'm forgetting, but why is it that the in
> >steps 1 and 4 of decrypt() that the document is serialized and parsed?
> > Why not just do the wrapping with the dummy nodes at the node-set
> > level?
>
> Because we don't have a concept to replace nodes in a node-set with other
> nodes whose owner is different from the one of the node-set.  To be
> concrete, we cannot replace an EncryptedData element node with a node (or
> nodes) obtained by parsing a fragment obtained by decrypting the
> EncryptedData element.  Therefore, we decided to parse a document as a
> whole to a new node-set.

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 in 
R. One might be able to perform an optimization such that if there are 3 
elements (e) in R, when decrypt(X,e,C) is called each time it re-uses the 
serialization of X from the first pass... Since C might be different for 
each e, I don't think anything else can be saved between iterations...

(I know this was discussed before but I've forgotten/become-confused about 
the requirements for serialization and dummy variables (I should go find 
the old email thread...))

Received on Tuesday, 18 September 2001 14:57:24 UTC