RE: octet-based processing model

Merlin,

I clearly misunderstood your concern (which is a good thing).  There was
a discussion of the basic issue you raise on-going at the time you sent
your initial mail.  See: 

http://lists.w3.org/Archives/Public/xml-encryption/2001Aug/0049.html
http://lists.w3.org/Archives/Public/xml-encryption/2001Aug/0050.html
http://lists.w3.org/Archives/Public/xml-encryption/2001Aug/0053.html

There seems to be agreement that we don't need to specify how
EncryptedData & EncryptedKey elements are communicated between the app
and Encryptor, nor how insertion into a doc context occurs, leaving it
an implementation decision.  I got a little over zealous in trying to
nail down representations in text I had suggested earlier.  (I will
disagree with your statement that this defined an API).

Unfortunately, I received your mail sometime after this discussion
thread and assumed you were concerned about something else.

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.

On decrypt-and-replace.  I've stated my preference for this being
recommended.  Those folks who believe it needs to be required should
probably comment.

Blair

-----Original Message-----
From: merlin [mailto:merlin@baltimore.ie] 
Sent: Monday, August 27, 2001 4:08 AM
To: Blair Dillaway
Cc: xml-encryption@w3.org
Subject: Re: octet-based processing model 



Hi Blair,

The need to define a standard serialization for plaintext of type
Element and Content is pretty much self evident.

What is not so clear, to me, is why we make the leap from this
requirement to actually defining the API to XML encryption in terms of
octet replacement.

I think that we state (among other things):

* At encryption time, return the EncryptedData as a UTF 8-encoded
  octet string.

  "[The EncryptedKey] will be encoded using the UTF-8 character set."
  "The EncryptedData element will be encoded using the UTF-8 character
set."

* At decryption time, replace the OCTETS of the EncryptedData in
  the original document with the decrypted plaintext octets,
  possibly after character encoding conversion.

  "In doing replacement please add back in a statement that changing the
   character encoding to that of the target document may be required."

If this is not what is meant, please correct me.

I don't buy this as the mandatory processing model. I think that we
should simply state:

* At encryption time, return the EncryptedData.

* At decryption time, either return the decrypted content, or
  replace the EncryptedData with this content.

Both of these processes could be done using octets, DOM, SAX, or
whatever is appropriate for the toolkit.

We seem to be specifying API/implementation details that unnecessarily
restrict the spec. What do we lose by simply dropping the mandatory
octet-based assumptions? Cryptors can still implement this, if they so
choose, but they can also choose other, possibly more appropriate,
models.

My "pragmatic" argument against required decrypt and replace* is that if
I implement an XML encryption toolkit that does not provide decrypt and
replace, and this is deployed in a Web service, can you, as a client,
tell? If not, why is my toolkit not compliant with XML encryption.

I'm just questioning why we are placing requirements like this in the
XML encryption spec. I don't believe that there are any such
requirements in the XML signature spec. Or are we purposefully going
down the twin paths of defining XML encryption and (bits of) its API?

Merlin

* My other argument is that it seems to prohibit models where there's no
such thing as "replace" (e.g. a stream of SAX events). If XML decryptors
must work in terms of octet strings, then we can require it - although I
still think it is a trivial implementation detail that should not be so
qualified - but if we move to a more general model, then I don't think
it can realistically be *required*. Surely it is just a "feature".

<----------- snip -------------->

Received on Monday, 27 August 2001 17:54:41 UTC