Re: octet-based processing model

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