Re: Why is Except limited to local fragments?

It might be prudent to require that, if an enc:EncryptedData is present
with a non-XML Type attribute, then it must be the (sole root element of
the input | only enc:EncryptedData in the input). Otherwise, operation
is ambiguous; we don't define an order for performing decryptions,
and the current language will return the data from the first non-XML
ciphertext processed.

Also, text that I'd suggest adding about the Except URI would be along
the lines of:

When dereferencing Except URIs, the application MUST behave as if the
root document node of the input node set is used 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. If the input is a different document
then, as per the XPointer spec, use of the here() function is an error.

Merlin

r/reagle@w3.org/2002.03.06/15:51:07
>
>Ok, this is represented in [1] with some tweaks. 
>
>http://www.w3.org/Encryption/2001/Drafts/xmlenc-decrypt 
>$Revision: 1.30 $ on $Date: 2002/03/06 20:50:31 $ GMT by $Author: reagle $ 
>
>On Monday 04 March 2002 10:49, Takeshi Imamura wrote:
>> >> We may need a fragment of text to further clarify XPointer support
>> >> when it is applied to a different document from the signature.
>> >> In such a case, here() is an error and the XPointer initial context
>> >> is the root of the new document? We don't have this problem with
>> >> XPointers in dsig because they always refer to the same document.
>> >
>> >I'm not sure I understand this, I'll defer to the authors. <smile/>
>>
>> Merlin, you are right.  As you say, we should add some text for XPointer
>> support.  Can you suggest it?
>>
>> >> On a separate note, should we profile the decryption transform to
>> >> allow non-XML content (output is an octet stream)?
>> >
>> >We discussed the scenario below in September and Hiroshi suggested we
>>
>> would
>>
>> >need a new function:
>> >  Instead, we should define a new function that decrypts an
>> >  xenc:EncryptedData element with a type other than Element
>> >  or Content to an octet stream.  Also we have to state that
>> >  when such an xenc:EncryptedData element is being
>> >  decrypted, the input to the transform has to be a node-set
>> >  that has the xenc:EncryptedData element as the first node.
>> >  http://lists.w3.org/Archives/Public/xml-encryption/2001Oct/0000.html
>> >
>> >As is my tendency I tend not to push for something unless someone says
>>
>> they
>>
>> >want it. Hiroshi/Takeshi, is Merlin's usage scenario the same as what
>> > you were thinking? If so, would you like to propose some text?
>>
>> If such a scenario is necessary, we could support it by changing the
>> processing rules slightly.  They would be roughly as follows:
>>
>> Z = decryptIncludedNodes(X, R)
>> 1. Select an EncryptedData element within X (say e) that is not
>> referenced by any Except element in R, or return X if such e cannot be
>> selected. 2. If the value of the Type attribute of e is Element or
>> Content, 2.1. Let C be a parsing context of X.
>>      2.2. Let Y be decrypt1(X, e, C).  If this function succeeds, replace
>> X with Y.
>>      2.3. Go to Step 1.
>>    Else
>>      2.4. Let Y' be decrypt2(X, e).
>>      2.5. Return Y'.
>>
>> Y = decrypt1(X, e, C)
>> 1. Let Y' be decrypt2(X, e).
>> 2. Wrap Y'in the context of C into an octet stream.
>> 3. Parse the octet stream into a node-set.
>> 4. Trim the node-set into Y.
>> 5. Return Y.
>>
>> Y' = decrypt2(X, e)
>> 1. Convert X into an octet stream.
>> 2. Decrypt the element corresponding to e and replace it with the
>> resulting octet stream into Y'.
>> 3. Return Y'.
>>
>> Note that the input is still a node-set and the output is a node-set or
>> octet stream depending on the input.
>>
>> Thanks,
>> Takeshi IMAMURA
>> Tokyo Research Laboratory
>> IBM Research
>> imamu@jp.ibm.com
>
>-- 
>
>Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
>W3C Policy Analyst                mailto:reagle@w3.org
>IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
>W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/
>


-----------------------------------------------------------------------------
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 by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
   http://www.baltimore.com

Received on Wednesday, 6 March 2002 16:31:19 UTC