Re: Decryption Transform processing question

Joseph,

Thank you for the comments.

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

I agree because the processing rules have been changed pretty much.

>  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()" .

These sound good.

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

OK, I will try to make such an example later.

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

I agree, but I think that this sentence is still confusing.  To my
understanding, "apex elements" are those of the node-set and "attributes"
are those of ancestors of the element being replaced.  Merlin, is that
correct?

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

It might be.  In that case, a gzipped PNG file cannot be converted to a
node-set and hence it is treated as an octet stream.  However, parsing
performed in Step 4 of foo() will fail anyway.  For this reason, I added to
Step 4 a sentence allowing to restart processing without replacing
EncryptedData elements.

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

An entity reference "∪" is used to indicate a union of sets.  It is
defined in [1].

[1] http://www.w3.org/TR/html401/sgml/entities.html

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

This is Step 3 of foo().  Merlin used this term, and so did I.

>     * 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 )

OK, I will try later.

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

It seems that these have been already fixed by you, thanks.

Thanks,
Takeshi IMAMURA
Tokyo Research Laboratory
IBM Research
imamu@jp.ibm.com

Received on Friday, 5 July 2002 00:33:06 UTC