Re: Why is Except limited to local fragments?

r/reagle@w3.org/2002.03.07/12:25:01
>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:
><foo>
>  <EncryptedData MimeType="msword"/>
>  <EncryptedData MimeType="png"/>
></foo>
>
>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 
>one?

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
   octets:
      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.

merlin

>> 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.
>
>Ok:
>
>http://www.w3.org/Encryption/2001/Drafts/xmlenc-decrypt.html#processing
>$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.
   http://www.baltimore.com

Received on Thursday, 7 March 2002 13:09:31 UTC