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

hal@finney.org wrote:
>Gerald Huck & Arne Priewe, priewe@darmstadt.gmd.de, write:
>> Dear Hal,
>>
>> >Requirements R4.1 and the one below R4.2 (misnumbered as R4.1.3) read,
>> >"XES MUST define an encryption mapping from plain-text XML-documents 
to
>> >encrypted ones," and "The result of decrypting an encrypted 
XML-document
>> >MUST be a well-formed XML-Document."
>> >
>> >I didn't see a statement that decrypting an encrypted document should
>> >give you back what you started with.
>>
>> This is not possible as a recipient may possess only a part of the
>> required keys. Thus we can maximally specify how such a partially
>> decrypted document must be represented.
>
>I think there should be something in the requirements that relates to the
>sense in which decryption is the inverse of encryption.  Presumably it
>is to be an inverse modulo some equivalence class of XML.  That is, if
>you start with some XML, encrypt it and then decrypt it, the end result
>is equivalent to the original under some set of rules which define an
>equivalence class.  Part of the work of the group needs to be to define
>that equivalence class, and/or to define a mechanism to specify the
>equivalence class (some kind of canonicalization transform).

You're right. That's better than our R4.2 (or R4.1.3).

>> >It seems to me that we have the power to give back bit for bit what 
was
>> >encrypted, since that is how encryption algorithms work.  This would 
of
>> >course provide equivalence for the widest set of requirements.
>>
>> If we can agree on the logical representation level this makes sense.
>> Technologically parsers do not give you all the physical information 
which
>> would be required for bitwise physical representation encryption.
>> E.g. the white space between attributes or their order is lost.
>
>I realize that this is a practical limitation.  It seems to me that it
>would be possible in principle to design a parser which would allow this
>behavior.  For example, parsed nodes could have information included in
>them which specifies the offset in the file where the node's data begins.
>Then encrypting a contiguous set of nodes could be done by looking up
>the start and end offsets in the file where that data originated, and
>encrypting that as a character string.
>
>However, given that current parsers don't work this way, it would
>be excessively burdensome to require bit for bit identity across the
>encrypt/decrypt transform.

That's what we think, too.

>
>> If an application requires a particular physical format, e.g. c14n, 
this
>> should be an optional transformation, but not a default as many other
>> applications may not require such a representation form.
>>
>> By the way we think that simple serialization algorithms like reading 
the
>> plaintext bit for bit are harmfull in general.
>> E.g. if schema informations exist at encryption time that include 
default
>> attribute values, these default values are lost. Assuming further that
>> the original schema definition is not accessible at decryption time,
>> these values can't be restored.
>
>The same is true if the document is sent unencrypted, isn't it?  If there
>is no schema available at the receiving end, and the document relies on
>default attributes, they will not be available.  Why is it the job of
>encrypt/decrypt to solve this when the problem is present in ordinary
>XML transfers?

Sorry. I liked to give you a use case thats as simple as possible.
But you are right - the above is too simple to show the problem.

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).


Arne Priewe

Received on Thursday, 30 November 2000 13:37:50 UTC