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

Re: Updated Section 4.

From: merlin <merlin@baltimore.ie>
Date: Thu, 23 Aug 2001 12:39:25 +0100
To: reagle@w3.org
Cc: "Blair Dillaway" <blaird@microsoft.com>, "XML Encryption WG" <xml-encryption@w3.org>
Message-Id: <20010823113925.86C4043BF6@yog-sothoth.ie.baltimore.com>

--8<--
4.1 Encryption
 ...
 5. EncryptedData Processing
  1. ... implementations MUST be able to return the UTF-8 encoding of the
EncryptedData element to the application ...
  2. ... then the UTF-8 encoded EncryptedData element is always returned
to the application ...
-->8--

Why must we return the UTF-8 encoding of this element? This precludes
returning, for example, a DOM structure. I would remove "the UTF-8
encoding of" and "UTF-8 encoded", so toolkits can operate as they desire.

I don't understand why crypt and replace - a mere implementation detail,
and nothing to do with interoperability - should be REQUIRED. If I
implement element encryption from, for example, a SAX source, then I
cannot formally replace, and so I cannot be compliant with this spec.
I can provide the required data for the application to replace (e.g.,
a stream of SAX events) but does that actually comply with replacement?

Merlin

r/reagle@w3.org/2001.08.22/17:28:07
>Thanks Blair, it's now clear it was under-specified before! <smile/>
>
>I've had a go as well. I made a bunch of tweaks but I think most are for the 
>best. (If I missed something, please push back.) Some of the substantive 
>tweaks/questions I have are:
>
>1. On the replace, do we need to force the encoding of EncryptedData during 
>encryption? (Probably so....)
>2. Also, I thought we agreed that the encrypt and replace was REQUIRED to 
>implement but optional to use?


-----------------------------------------------------------------------------
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, 23 August 2001 07:40:14 GMT

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