W3C home > Mailing lists > Public > xml-encryption@w3.org > March 2002

Re: Why is Except limited to local fragments?

From: merlin <merlin@baltimore.ie>
Date: Fri, 08 Mar 2002 18:41:26 +0000
To: reagle@w3.org
Cc: "Takeshi Imamura" <IMAMU@jp.ibm.com>, "Hiroshi Maruyama" <MARUYAMA@jp.ibm.com>, xml-encryption@w3.org
Message-Id: <20020308184126.914474422C@yog-sothoth.ie.baltimore.com>
>On Friday 08 March 2002 03:03, Takeshi Imamura wrote:
>> I basically agree on this, but I think we should state such a restriction
>> on X in Section 2.1.2.  I tried to make some tweak to Section 2, which is
>> attached below.  Could you check if I misunderstand anything?
>> (See attached file: 20020308.html)
>Looks good, now in the editors' draft [1]. My two questions:
>1. Do we even need to talk about Z? According to decryptIncludedNodes, Z is 
>always a nodeset, but it's not even mentioned in the "if XML" in step 2, 
>and it is mention in the "if octets" in step 3.
>2. I'm a little confused by this wording, "If an xenc:EncryptedData element 
>node being decrypted is the first node in X, the value of its Type 
>attribute MUST NOT be  xenc;Content. Otherwise, the value MUST be  
>xenc;Element or  xenc;Content."
>Can we be confident that we have the ordering of the nodes in X?
>Perhaps we should give a little motivation (to help me and eventually 
>others understand). Perhaps,
>If an xenc:EncryptedData element node being decrypted is the first node in 
>X, the value of its Type attribute MUST NOT be  xenc;Content. This prevents 
>an ill-formed XML document with element content appearing at the start of 
>the document. If the xenc:EncryptedData is not the first node in X, the 
>value MUST be  xenc;Element or  xenc;Content. This prevents binary data 
>from appearing out of place in an XML document. 

I think this paragraph looks good, although "with element content
appearing" should perhaps be "with invalid content appearing"?

Should we generalize to allow a single non-XML EncryptedData
to appear anywhere in the excepted input, rather than requiring
that non-XML EncryptedData be the root node?

... 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 mixed decryption of XML and non-XML data,
and restricts the decryption transform to a single piece of
binary data at a time.

I'm not terribly pushed on this, it might just make some uses
easier; for example, I can reference an external XML document
containing one piece of encrypted binary data that is not the
root, without using an XPath transform to select the encrypted
data element; somewhat like the base-64 transform ignoring XML


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.
Received on Friday, 8 March 2002 13:41:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:03 UTC