- From: Joseph M. Reagle Jr. <reagle@w3.org>
- Date: Fri, 30 Mar 2001 17:19:16 -0500
- To: "John Boyer" <JBoyer@PureEdge.com>
- Cc: "Hiroshi Maruyama" <MARUYAMA@jp.ibm.com>, <xml-encryption@w3.org>, <w3c-ietf-xmldsig@w3.org>, <Andy_Clark/Santa_Teresa/IBM@jp.ibm.com>
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
C14N.
><john>
>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.
></john>
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)))
><john>
>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.
></john>
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. http://www.w3.org/People/Reagle/
W3C Policy Analyst mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair http://www.w3.org/Signature
W3C XML Encryption Chair http://www.w3.org/Encryption/2001/
Received on Friday, 30 March 2001 17:19:30 UTC