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

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

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

> 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?

Hal Finney
PGP Security

Received on Monday, 20 November 2000 20:47:32 UTC