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

Re: Why is Except limited to local fragments?

From: Takeshi Imamura <IMAMU@jp.ibm.com>
Date: Mon, 11 Mar 2002 17:20:10 +0900
To: reagle@w3.org
Cc: merlin <merlin@baltimore.ie>, "Hiroshi Maruyama" <MARUYAMA@jp.ibm.com>, xml-encryption@w3.org
Message-ID: <OF623BE216.3ED38F2C-ON49256B79.0028A3DE@LocalDomain>

>> >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"?
>I struggled with that, perhaps I should reuse the "ill-formed" again.
>Binary data can appear if it's in CDATA I think, so I don't want to make
>seem like that could never happen. (And invalid content seems to presume

The first restriction is a restriction for ensuring that a node-set is
always single-rooted rather than preventing an ill-formed XML document or
an XML document with invalid content.

>> 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
>> data.
>I don't feel very strongly but I would prefer not.

I support Merlin.  Actually his suggestion is what I intended in the
original text by "an xenc:EncryptedData element node being decrypted".
That is, EncryptedData element nodes referenced by Except elements can
appear anywhere in a node-set and should be ignored when checking if
restrictions on the Type attribute are satisfied.  This is not only the
case for non-XML EncryptedData element but the case for XML EncryptedData

Tokyo Research Laboratory
IBM Research
Received on Monday, 11 March 2002 03:20:20 UTC

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