RE: XML Encryption Data/Processing Model

At 10:33 3/30/2001 -0800, John Boyer wrote:
>Your problem has little to do with a 'consistency' issue on C14N, and is
>trivially solvable.  The solution you are considering is fraught with
>problems.  Details below.

I fear that it is not trivially solvable, but it's not through any fault of 

>As to your practical problem, it does not appear to have a very
>difficult solution.  The fact that it is a sign-then-encrypt scenario
>does not mean you are restricted to two black box operations to be done
>in precisely that sequence.  If you know it is a sign then encrypt, then
>you should simply apply the C14N to the block to be encrypted, then
>affix the signature, then perform the encryption.

If you are a single signor-encryptor this works, but it doesn't if its two 
different parties. Consequently we need to define an encryption process that 
allows one to serialize and then encrypt some portion of a parsed document 
such that the decrypt leaves it in as untouched a state as possible:
         canonicalize(foo) == canonicalize(decrypt(encrypt(foo)))

>When you C14N the <el2enc> element, you are canonicalizing it outside of
>the context of its parent, so transferring the xml:lang into the element
>is necessary.  To wit, you may have an application scenario where you
>send only the encrypted blob (containing the scrambled version of the
><el2enc> element) to the holder of the appropriate private key.  The
>absence of xml:lang in such a case would be detrimental.

I think I agree with this: this is a fine behavior for canonicalizing prior 
to signature. But it is problematic as Hiroshi describes for serialization 
of the parsed XML that is about to be encrypted.

So in the relation, where foo is some parsed XML (a node or item), the bit 
is we need an XML serialization algorithm that maintains the identity:
         canonicalize(foo) == canonicalize(decrypt(encrypt(serialize(foo))))
the question we are considering is can serialize=canonicalize and Hiroshi 
has pointed out a case where this is problematic.

Joseph Reagle Jr.       
W3C Policy Analyst      
IETF/W3C XML-Signature Co-Chair
W3C XML Encryption Chair

Received on Friday, 30 March 2001 17:19:30 UTC