Re: Why is Except limited to local fragments?

Being able to specify a document containing encrypted non-XML data at
a location other than the root would be convenient for some situations,
but can be solved with an XPath transform.

I view this as similar to the base-64 transform: It can take XML input
and will discard non-text nodes.  We could have required an explicit XPath
self::text() transform, but we chose to make the text-node filtering
implicit because XPath support is not REQUIRED by dsig.

So yes, like the base-64 transform, the other nodes are simply thrown
away. Implicit operations like this do raise 'know what was signed'
concerns, but they are not new to dsig.

However, absent any other desire for this use, I'm happy to defer to
Takeshi's text.

Merlin

r/reagle@w3.org/2002.03.27/18:21:21
>[Merlin, question for you at the bottom.]
>
>On Friday 22 March 2002 14:07, Takeshi Imamura wrote:
>> necessary:
>> >http://www.w3.org/Encryption/2001/Drafts/xmlenc-decrypt
>> >$Revision: 1.36 $ on $Date: 2002/03/18 18:45:50 $ GMT by $Author: reagle
>> > $
>> >
>> >o If an xenc:EncryptedData being decrypted is the first node in X, the
>> >value of its Type attribute MUST NOT be &xenc;Content. This ensures the
>> >result is always rooted by a single element.
>
>Ok, reflected in:
>
>http://www.w3.org/Encryption/2001/Drafts/xmlenc-decrypt 
> $Revision: 1.37 $ on $Date: 2002/03/27 23:17:41 $ GMT by $Author: reagle $
>
>
>> This ensures that if Type is Element, the result is a single-rooted
>> node-set, and otherwise, the result is binary data.
>>
>> >If the xenc:EncryptedData is not the first node in X and its type is
>> >neither &xenc;Element nor &xenc;Content, then it MUST be the only
>> >xenc:EncryptedData in X not referenced by an Except element. This
>> > prevents the mixed decryption of XML and non-XML data and restricts the
>> > decryption transform to a single piece of binary data.
>>
>> Sorry, I don't understand this.  In this case, after decryption, how are
>> nodes other than the EncryptedData element node and its descendant nodes
>> treated?  Are they thrown away?  If yes, it seems strange to me.  I would
>> like to propose the text like "If an xenc:EncryptedData element node
>> being decrypted is not the first node in X, the value of its Type
>> attribute MUST be &xenc;Element or &xenc;Content.  This ensures that the
>> result is always a node-set."  How do you feel?
>
>I find your text much simpler, however Merlin is the one that proposed the 
>present text and wants to be able to pull a single chunk of binary data out 
>of an XML document, so I'd like him to respond to your question.
>
>-- 
>
>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 Thursday, 4 April 2002 12:31:59 UTC