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

Re: octet-based processing model

From: merlin <merlin@baltimore.ie>
Date: Thu, 30 Aug 2001 13:12:50 +0100
To: "Blair Dillaway" <blaird@microsoft.com>
Cc: xml-encryption@w3.org
Message-Id: <20010830121250.7F64A43BCE@yog-sothoth.ie.baltimore.com>
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 Thursday, 30 August 2001 08:13:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:04 UTC