Re: Decryption Transform processing question

On Monday 24 June 2002 12:24 pm, Takeshi Imamura wrote:
> I'm sorry to be late, but please find the updated draft below.  In the
> draft, I borrowed most of Merlin's text and also tried to clarify the
> processing rules by dividing them in two functions.  I gave up supporting
> binary decryption combined with XML decryption because it seems to be
> difficult to gain your support.  So if necessary, I can add to the draft
> a section for the binary-mode.  Anyway, any comments are welcome.

Thanks Takeshi! I have some comments below but I'll defer subsantive 
discussion of the binary modes to Merlin.

Comments on [1].

[1] 
http://lists.w3.org/Archives/Public/xml-encryption/2002Jun/att-0067/01-20020624.html

2 Decryption Transform

   Identifier:
          http://www.w3.org/2001/04/decrypt#

We should use a different identifier. I propose:
	http://www.w3.org/2002/06/decryt#

  2.1 Processing Rules
   transform are those of the foo() function, which itself calls the
   bar() function.

How about "stage()" (or maybe "marshal()") and "decrypt()" .


   O = foo(N, E)
          where N is a node-set and E is a set of exception URIs held by
          URI attributes of dcrpt:Except elements. O is a node-set,
          computed as follows:

         1. Dereference each exception URI from E in the context of the
            owner document of N, resulting in a set of XPointer
            location-sets [XPointer] X.
               o When dereferencing an exception URI, the implementation
                 MUST behave as if the document node of the input
                 node-set is used to initialize the XPointer evaluation
                 context [XPointer], even if the node is not part of the
                 node-set. Unlike XML Signature [XML-Signature], the
                 exception URI may be evaluated against a different
                 document from the signature document. If the input is a
                 different document then, as per XPointer [XPointer], use
                 of the here() function is an error.

An explicit example of this might be useful.

         3. Convert N to an octet stream as described in The Reference...
               o If a node-set is replacing an element from N whose
                 parent element is not in N, then its apex elements MUST
                 inherit attributes associated with the XML namespace
                 [XML] from the parent element.

I'm still not sure I completely understand this, and consequently it'd be 
nice if this was shown in the example in section 4. Also, if we do need to 
do this, I think we'd have to say, "then its apex elements MUST inherit 
attributes associated with the XML namespace[XML] from nearest *ancestor* 
element."


   Y = bar(N, X)
         3. For each xenc:EncryptedData element d from D:
               o If the Type attribute is absent or its value is neither
                 &xenc;Element nor &xenc;Content, the result is an octet
                 stream in default. However, the implementation MAY
                 process it further in accordance with its type, if any,
                 resulting in a node-set.

I'd remove the "in default". Also, I think what is returned should be 
determined by the type. For instance, it might be a gzipped PNG file.

         2. Replace Y with Y )U {O[d]}.

Whatever character is being used between the Y and the {O[d]} is not be 
represented well on any of my browsers.

  2.2 Restrictions and Limitations
     * The octet stream resulting from canonicalization-with-replacement
       MUST be well-formed.

Which process was this? (Perhaps we should label it as such?)

     * Super-encryption may cause problems if a super-encrypted
       xenc:EncryptedData element uses same-document references, or if an
       exceptional super-encrypted xenc:EncryptedData element is
       referenced by a URI with an XPointer except a full XPointer
       "xpointer(id('ID'))" and bare name. 

I think it's very important that we have some examples for these 
same-document references and such. (As we  had to do in xmldsig
  http://www.w3.org/TR/xmldsig-core/#sec-ReferenceProcessingModel )

4 Example
    3. As a result, D for N is a node-set consisting of the two
...
       Note that part of the second node-set ([02]) has been
       super-encrypted.
    4. After this decryption stage, two new xenc:EncryptedData elements
       ([03] and [02]) have been revealed. However, the first matches an

I don't think you need the "Note..." since this is exactly what step 4 
says. Also, in the example it might be worthwhile to give the different 
"layers" of instance different letters, like [a01-a15] [b01-b28], etc.

Received on Tuesday, 25 June 2002 15:15:38 UTC