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