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, 01 Mar 2002 17:05:49 +0000
To: reagle@w3.org
Cc: "Takeshi Imamura" <IMAMU@jp.ibm.com>, "Hiroshi Maruyama" <MARUYAMA@jp.ibm.com>, xml-encryption@w3.org
Message-Id: <20020301170549.615AF43CEA@yog-sothoth.ie.baltimore.com>
r/reagle@w3.org/2002.03.01/11:55:28
>On Friday 01 March 2002 03:54, Takeshi Imamura wrote:
>> Thanks, Joseph.  It looks good, but a parenthesis is missing after
>> "[XML-Signature, Section 4.3.3.2])".
>
>Ok, fixed.
>
>> As to IDREF vs. non-empty same-document URI reference, IDREF would be
>> sufficient for most cases, but we should not preclude a case where an
>> XPointer is used because one may use it.  Note, we should specify all
>> support for XPointers except barename XPointer and "#xpointer(id('ID'))"
>> as OPTIONAL, like XML-Signature.
>
>Agreed.

We may need a fragment of text to further clarify XPointer support
when it is applied to a different document from the signature.
In such a case, here() is an error and the XPointer initial context
is the root of the new document? We don't have this problem with
XPointers in dsig because they always refer to the same document.

On a separate note, should we profile the decryption transform to
allow non-XML content (output is an octet stream)? I have a customer
who wants to be able to have a signature over encrypted binary data;
our current answer is to use a signature with no URI, the data
implicitly being the decryption result. They want:

<enc:EncryptedData Id="id" MimeType="text/plain">
  ...
</enc:EncryptedData>
<ds:Signature>
  <ds:Reference URI="#id">
    <ds:Transforms>
      <ds:Transform Algorithm="&decrypt-transform;" />
      <!-- result is the decrypted text -->
    </ds:Transforms>
  ...
</ds:Signature>

Merlin


-----------------------------------------------------------------------------
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 Friday, 1 March 2002 12:05:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:20 GMT