Re: Poll (Was: digest requirement)

Hi,

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.

Merlin

r/reagle@w3.org/2001.09.26/19:25:42
>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.
>
>[1] 
>http://lists.w3.org/Archives/Public/xml-encryption/2001Sep/att-0021/01-digest.
>html
>


-----------------------------------------------------------------------------
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.
   http://www.baltimore.com

Received on Thursday, 27 September 2001 12:36:31 UTC