Re: Signing and Encryption

It occurred to me that we could perhaps approach the problem
of the interaction of encryption and signing in the following way:

Applying either signing or encryption to an original XML document
X0 results in a new document X1. There is enough information in
a well-formed X1 to recover X0.

If another stage of signing or encryption is applied to the result
of the first stage (X1), a new document X2 results.
Depending on exactly what was done, it may or may not be possible
to recover X1 from X2 unambiguously. In general it is not.
The more stages are applied, the worse it gets.

One proposal I've seen is that when applying
encryption that interacts with existing signatures the signatures
are modified to include extra information to make this clear.
Another proposal says leave it all alone - let the application sort it out.

If cascading encryption and/or signature is important, and I've seen
it argued that it is, it seems to me we should support it in general.
Either that or take the second approach above and leave it alone.

Modifying the signatures when encrypting sorts out one ambiguity,
but it does not solve the general case, cascading partial encryptions
for example.

For the moment I'm leaving aside any security problems caused by cascading
encryption - that seems to me to be a separate issue.

Anyway, if we want to support the general case it looks like we
need to add extra information to indicate what signing/encryption operation
(or other transform) has been applied to a document. In general, if
we start with X0 and generate a sequence X1, X2, ...., Xn by composing
operations, we need to add enough information to recover X(i-1) from Xi
for 1<=i<=n.

One way to do this would be to add a manifest to the document
indicating the contents affected by each stage. If at each stage
new elements are given an id the manifest could simply be a list
of the ids in order.  If earlier stages need hiding their manifests
could be encrypted. 

If X0->X1 were signing, and X1->X2 were encryption, it would then be clear
that the receiver would need to reconstruct X1 before checking any
signatures (and a fancy implementation could do just enough work to
allow signatures to be checked).

This approach should cope with the general case, and should be simpler
than the signature modifying approach, since the manifest for an operation
only needs to concern itself with what that operation did, and need not
worry about the detailed interactions with other constructs (like signatures).
This approach has the potential to support fairly general sequences
of reversible XML transformations other than signature or encryption.

Comments please,

Mike Wray (mike_wray@hp.com)

Received on Thursday, 1 February 2001 12:34:08 UTC