Re: Decryption Transform processing question

Hi Ari,

Sorry; would you believe it, I think I actually wrote the
paragraph that you quote[1]. I should probably hold off on
writing emails larger than 1 line until I can devote more
consistent cycles to them.

[1] http://lists.w3.org/Archives/Public/xml-encryption/2002Mar/0015.html

My original intent was to give an example with xpointer-based
relative URIs; #xpointer(here()/....). This will work for
single-phase processing but will fail for iterative
processing unless we serialize and parse X before we
do anything (in which case here() is meaningless and
XPointer will always be interpreted consistently although
bizarrely; that dummy element will exist as far as XPointer
is concerned).

With single-phase processing we don't need that change
in the interpretation of same-document references and
XPointers will not be interpreted in the context of a
dummy element.

Also, the parsing model that we specify (from XML signature)
is explicitly non-validating, and there is no DTD, so
ID resolution in the new document will not be consistent.

Is iterative decryption useful?

I think we have a choice between iterative decryption and
XPointer-based exceptions. If we choose iterative decryption
and XPointers, then we must start with a serialize/wrap/parse
step so that XPointers are interpreted consistently, and
we must note that #xpointer(/*) will resolve to a dummy
element.

Regardless, we should probably provide a note that the output
node set tree will actually be rooted by an absent dummy
element. This will be important for subsequent XPath transforms.

Merlin

r/arik@phaos.com/2002.05.02/13:56:35
>
>>My problem with iteration is:
>>   <Foo Id="foo">
>>     <EncryptedData>
>>   <!-- what was formerly
>>       <Bar>
>>       <EncryptedData Id="enc-1" />
>>       <EncryptedData Id="enc-2" /> -->
>>     </EncryptedData>
>>   </Foo>
>>
>>I can't run this through:
>>   Signature URI="#foo"
>>     Decrypt-Transform Except="#enc-2"
>>
>>During round 1, we get back a new node set with the original
>>pair of EncryptedData, but the URI #enc-2 will no longer resolve
>>because round 2 is processing a different document. So,
>>suggesting that this transform can handle multiple encryption
>>will only mislead people without a warning that Except elements
>>won't work for multiply-encrypted data. Somewhat more to the
>>point; because our Except references will no longer apply to
>>the new document, round 2 will try and decrypt every
>>EncryptedData that was excepted from round 1.
>
>I don't understand -- why wouldn't URI="#enc-2" resolve? The spec states in 
>the last paragraph of section 2.1,
>
>         [...] When dereferencing dcrpt:Except URIs, the application
>         MUST behave as if the root document node of the input node
>         set isused to initialize the [XPointer] evaluation context, even
>         if this node is not part of the node set. Unlike [XML-Signature],
>         the URI may be evaluated against a different document from
>         the signature document."
>
>In round 2 we re-initialize the evaluation context to the root document 
>node for X, regardless of the consideration that X may be a node-set over a 
>new document.
>
>
>Ari Kermaier    arik@phaos.com
>Senior Software Engineer
>Phaos Technology Corp.    http://www.phaos.com/
>


-----------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the contents of this message by a third party or as a result of any 
virus being passed on.

This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
http://www.baltimore.com

Received on Thursday, 2 May 2002 14:27:30 UTC