- From: Takeshi Imamura <IMAMU@jp.ibm.com>
- Date: Mon, 3 Sep 2001 16:11:17 +0900
- To: merlin <merlin@baltimore.ie>
- Cc: "Blair Dillaway" <blaird@microsoft.com>, xml-encryption@w3.org
Merlin, >My question is simply, why do we have a MUST that the *app* (i.e., >not the xmlenc implementation) be responsible for the conversion to >and from octets, I think that as Blair wrote before, encryption and decryption operations are always performed on octets and hence it is natural for xmlenc implementations to expect such octets as input and output. The capability to accept input and output other than octets would be value-add to the implementations. >and a MUST that the xmlenc implementation be capable >of replacing part of an encoded character string with another encoded >(possibly differently) character string? If you develop an xmlenc implementation in a naive way, this capability is necessary because if a retrieved XML fragment replaces an EncryptedData element, the fragment has to parsed in the context of the EncryptedData element, e.g., namespace declarations, xml:lang declarations, entities, and so on. Thanks, Takeshi IMAMURA Tokyo Research Laboratory IBM Research imamu@jp.ibm.com From: merlin <merlin@baltimore.ie>@w3.org on 2001/08/30 21:12 Please respond to merlin <merlin@baltimore.ie> Sent by: xml-encryption-request@w3.org To: "Blair Dillaway" <blaird@microsoft.com> cc: xml-encryption@w3.org Subject: Re: octet-based processing model r/blaird@microsoft.com/2001.08.27/14:54:09 >I clearly misunderstood your concern (which is a good thing). Mea culpa; I wasn't clear. >Maybe I'm still missing something though. What do you mean by "What do >we lose by simply dropping the mandatory octet-based assumptions?" >Encryption/decryption always operate on octets. All we've said is the >app is responsible for the conversion from XML into octets and somehow >communicating this to the Encryptor. We've further suggested an encoding >for this if you want decrypt-and-replace to work. Which means there is >no required serialization alg for compliant implementations, but >certainly doesn't require any specific implementation approach. My question is simply, why do we have a MUST that the *app* (i.e., not the xmlenc implementation) be responsible for the conversion to and from octets, and a MUST that the xmlenc implementation be capable of replacing part of an encoded character string with another encoded (possibly differently) character string? (I recognize that you do not believe in mandatory replacement.) This means that my implementation MUST have an API (#3 is particularly egregious): bytes encrypt(bytes serialized, ...); bytes decrypt(...); bytes decryptAndReplace(bytes document, index from, index to, token encoding, ...); If we remove the mandate that the input and output to the xmlenc implementation MUST be the octets of encoded strings, we open up APIs to being much more flexible; in particular, in environments where the application never normally sees serialized XML documents. 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. 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 Monday, 3 September 2001 12:44:08 UTC