- From: Joseph Reagle <reagle@w3.org>
- Date: Tue, 16 Jul 2002 11:28:57 -0400
- To: merlin <merlin@baltimore.ie>
- Cc: "Takeshi Imamura" <IMAMU@jp.ibm.com>, xml-encryption@w3.org
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.
Received on Tuesday, 16 July 2002 11:29:05 UTC