W3C home > Mailing lists > Public > xml-encryption@w3.org > July 2002

Re: Decryption Transform processing question

From: merlin <merlin@baltimore.ie>
Date: Tue, 16 Jul 2002 16:34:08 +0100
To: reagle@w3.org
Cc: "Takeshi Imamura" <IMAMU@jp.ibm.com>, xml-encryption@w3.org
Message-Id: <20020716153408.6088843D9D@yog-sothoth.ie.baltimore.com>

r/reagle@w3.org/2002.07.16/11:28:57
>On Monday 15 July 2002 03:27 pm, merlin wrote:
>> The Foo element is an apex node of the signed node set and so when the
>> decrypt transform performs c14n-with-replacement, it inherits xml:lang.
>> Later on, this is encrypted:
>>
>>   <Document xml:lang="ie">
>>     <EncryptedData Id="foo-1" [[<Foo Id="foo-1" />]] />
>>     <Signature xmlns="&dsig;"> ...
>>       <Reference URI="#foo-1"> ...
>>       <Transform Algorithm="&decrypt;XML" /> ...
>>     </Signature>
>>   </Document>
>>
>> Now, when we do the c14n-with-replacement within the decrypt
>> transform, the Foo element will not inherit xml:lang correctly
>> because it is in a different document; as a result, the signature
>> will break. So we need that patch text.
>
>Yes, I remember this from our discussion from on the dsig list re:exc-c14n. 
>(I was confused for a bit because I forgot that the Foo element is a 
>different document, and consequently doesn't inherit xml:lang ). However, I 
>also remember not trying to entangle the encryption processing with a given 
>c14n algorithm, but if we had to, we should choose exc-c14n. As it stands, 
>if you add these attributes to an exc-c14n you'll break it. (Right?) 
>Consequently, given that we created exc-c14n because c14n was bad at 
>serializing fragments that change documents/context, I see no reason to 
>address extra processing for c14n. If folks want the xmldsig decryption 
>transform, they should use exc-c14n-like signatures -- if that does the 
>trick.

You're recalling my earlier confusion which turned out to be misplaced.
The c14n is performed internally within the decryption transform; it is
not the signature canonicalization; and it is fixed as standard c14n. This
is the final c14n-with-replacement/parse step done by the decryptXML()
function. So we have no choice but to solve the problem, and it doesn't
have an impact on subsequent signature c14n/exc-c14n processing.

Merlin
Received on Tuesday, 16 July 2002 11:34:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:21 GMT