- From: Dournaee, Blake <bdournaee@rsasecurity.com>
- Date: Mon, 29 Oct 2001 15:19:57 -0800
- To: reagle@w3.org
- Cc: xml-encryption@w3.org
Joseph, I'm still not convinced that C14N should be the recommended method of serializing in all cases (which is what is implied in the current draft). Converting from XML to octets using C14N is horribly slow. Moreover, the problem that Takeshi mentions has to do with the interaction between XML signatures and XML encryption. When would C14N be recommended for XML Encryption alone? Recommending C14N for certain circumstances is fine, but this seems like a fringe case that is not part of the basic use-cases of XML Encryption (encrypt element, content, or arbitrary octets). Thanks, Blake Dournaee Toolkit Applications Engineer RSA Security "The only thing I know is that I know nothing" - Socrates -----Original Message----- From: Takeshi Imamura [mailto:IMAMU@jp.ibm.com] Sent: Thursday, October 25, 2001 8:04 PM To: reagle@w3.org; Dournaee, Blake Cc: xml-encryption@w3.org Subject: Re: Question about EncryptedType Joseph, >Technically speaking, I'd argue they are *not* in conflict. 4.1 says to >serialize, and 5.9 says one of those ways to serialize is c14n. However, I >do agree with you that it makes one wonder when one should use c14n. I >don't think anything in xenc requires c14n. If you need to c14n, it would >relate to integration with xmldsig. Based on my email [1] with Takeshi >regarding the Decryption Transform, it might not even be needed there. > >So Takeshi, where does one use c14n when used with xmldsig, and should we >say it is recommended at all? The c14n is useful in a case, for example, where the outer context of the fragment which was signed and then encrypted may be changed. Otherwise the validation of the signature over the fragment may fail because c14n may include unnecessary namespaces into the fragment. In this case, the decryption transform does not help. So I think that c14n should be recommended. Thanks, Takeshi IMAMURA Tokyo Research Laboratory IBM Research imamu@jp.ibm.com
Received on Monday, 29 October 2001 18:20:06 UTC