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: Thu, 07 Mar 2002 18:09:25 +0000
To: reagle@w3.org
Cc: "Takeshi Imamura" <IMAMU@jp.ibm.com>, "Hiroshi Maruyama" <MARUYAMA@jp.ibm.com>, xml-encryption@w3.org
Message-Id: <20020307180925.A3EC24422C@yog-sothoth.ie.baltimore.com>
>On Wednesday 06 March 2002 16:31, merlin wrote:
>> 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.
>I'm not sure what you mean by "operation is ambiguous" and "don't define an 
>order for performing decryptions." I think I understand your point: it's 
>difficult to envision someone having:
>  <EncryptedData MimeType="msword"/>
>  <EncryptedData MimeType="png"/>
>but there might be one... and then with respect to the "only 
>encEncryptedData in the input", I think the input could have more than one 
>EncryptedData, but that input less those excepted would have to be equal to 

This is the example I'm considering; assume <foo> above is the
input and there is no Except. We state:

   1.   Within X, select e, an element node with the type
   enc:EncryptedData, ...

We don't place an ordering on selecting e, so a decryptor may
choose either the msword or png data first.

   3.  If the value of the Type attribute is absent or otherwise indicates
      1. Let Y' be decryptOctets(X, e).
      2. Return Y'.

This returns the first non-XML encrypted data encountered,
which is what I meant by ambiguous operation.

I think, as you suggest, we should require that the input less
those excepted must have only one encrypted data of non-XML type.


>> 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.
>$Revision: 1.32 $ 
>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.
Received on Thursday, 7 March 2002 13:09:31 UTC

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