W3C home > Mailing lists > Public > xml-encryption@w3.org > December 2000

Re: Requirements and Goals for the Design of an 'XML Encryption Standard'

From: <hal@finney.org>
Date: Fri, 8 Dec 2000 10:37:27 -0800
Message-Id: <200012081837.KAA12433@finney.org>
To: hal@finney.org, priewe@darmstadt.gmd.de, xml-encryption@w3.org
Cc: huck@darmstadt.gmd.de
Arne Priewe writes:
> We are thinking on applications that aggregate information from
> different sources that may be encrypted. Eg a workflow in which
> a slideshow is created and some of the included pages come from
> encrypted sources. Only the final receiver has the key to decrypt all 
> pages.
> So at aggregation time there is no way to add eg default attributes or
> namespaces to the encrypted data. Nor could the receiver do this,
> because the schema information is lost.
> So this can only be done at encryption time 
> (of course only if the schema information is availabale).

To see if I understand this, the order in which things might
happen would be as follows:

 - First, a partial document is created by one workgroup.  It uses
   a schema with default attributes, etc.

 - Second, this document is encrypted, using a key that is held only
   by the final viewer of the document.

 - Third, this document gets aggregated with others.

 - Fourth, the schemas are going to be removed before transmittal,
   so the aggregator goes through the document and "canonicalizes" it,
   transforming it into a document with explicit attributes that don't
   rely on defaults.  Perhaps he would expand entities and do other such
   transformations as well.

 - Fifth, the document is transmitted, without schemas.

 - Sixth, the final viewer decrypts the encrypted portions of the
   document and views it.

The problem is in step 4, he can't expand things in the encrypted
portion.

Your proposal, I believe, is that therefore we should specify a transform
where we expand things (that is, substitute default attributes, etc)
before encrypting.  Or perhaps you are suggesting that we should always
expand things before encrypting?

It's not clear to me why, if we do this expansion, we have to document it
with a transform.  The decryption engine would not use this information,
would it?  It's not like it can reverse the transform.

Shouldn't this transform be thought of as something that is done
independently of encryption?  It seems to me that it is a choice on
the part of the encryptor what format to pass into the encryption
layer.  An author may avoid using default attributes altogether if he
anticipates the workflow problem above.  The net result is the same
as if he used defaults, but expanded them with a transform immediately
before encryption.  Yet in the first case, there would be no transform
specified in the encryption data, and in the second place, there would.
Why would we want the resulting encrypted output to look different in
the two cases?

Another point is that I don't believe this transform should be always
done, and I question whether it should be the default.  Although it is
advantageous in the example above, one can easily conceive of situations
in which it would be incorrect.  For example, if the schema is being
transmitted, and the aggregator in step 4 above wants to edit some of
the defaults in the schema.  If we have expanded them already his edits
won't take effect within the encrypted portions.

I think we need to determine whether doing expansion helps in more cases
than it hurts, before we decide that it should be the default.

Hal Finney
Received on Friday, 8 December 2000 13:36:04 GMT

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