W3C home > Mailing lists > Public > xml-encryption@w3.org > September 2001

Re: Poll (Was: digest requirement)

From: merlin <merlin@baltimore.ie>
Date: Thu, 27 Sep 2001 17:36:22 +0100
To: reagle@w3.org
Cc: "XML Encryption WG" <xml-encryption@w3.org>
Message-Id: <20010927163622.6DEAA43BC2@yog-sothoth.ie.baltimore.com>


One flaw with [1] is that Reference URI="foo.xml#bar" is not valid.
Rather, you need URI="foo.xml" followed by an XPath or XPointer transform
to select the appropriate element.

However; I would vote for 1, and furthermore I would suggest that [1]
with any necessary cleanup would be more appropriate as a separate
informational document. I don't think it represents a core part of XML
encryption syntax or processing.


>Please respond to the list by close of Friday the 28th.
>In [1], I summarize the requirement to partially reveal/decrypt and confirm 
>the authenticity/integrity of elements without necessarily revealing other 
>elements encrypted at the same time -- and how to achieve this using 
>xmldsig. Do you prefer:
>1. Remove the Digest{Method,Value} and specify how similar functionality 
>can be accomplished using an XML Signature manifest as described in [1]. 
>This is a bit more clean with respect to keeping xmldsig and xenc distinct 
>(we'd have no special syntax or processing specified in xenc), but requires 
>slightly more complex specification none-the-less (of how to use xmldsig) 
>to satisfy the requirement.
>2. Retain the Digest{Method,Value} as presently specified. This introduces 
>additional processing into the Encryption spec for integrity purposes that 
>could be done by XML Signature, but it's a little more straightforward.
>This option also satisfies Amir's requirement of being able to change the 
>Encryption algorithm without invalidating a signature of the plain data and 
>digests *if* a transform is used to remove the actual Encryption Info 
>(algorithm, key and value) prior to a signature. However, this requires an 
>actual transform to be written. If you opt for #2, should we:
>A. Let applications specify the transform.
>B. Specify/standardize the transform.

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.

In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.

This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
Received on Thursday, 27 September 2001 12:36:31 UTC

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