- From: <edsimon@xmlsec.com>
- Date: Tue, 12 Jun 2001 11:44:37 -0400
- To: xml-encryption@w3.org
Don, Fundamentally, I agree with you; ultimately, the XML Encryption Recommendation does not need to discuss the reversibility of transforms in CipherReference because the transforms are only for acquiring the cipherdata and do not necessarily reflect on transforms peformed during the encryption stage. Nevertheless, the concept of what you get after decryption not being bit-for-bit or character-for-character the same as what you had before encryption needs to be understood by implementors and integrators of XML Encryption. They need to understand this because it is a new XML-security-specific concept, and is a bit of a paradigm shift from life before XML Encryption. Here's an extended example, You encrypt this <element attr1='blah1' attr2="blah2" >&proglang; code: <![CDATA[&i<2]]></element> and the decrypted result is <element attr2="blah2" attr1="blah1" defaultAttr="yes">C++ code: &i<2</element> This may be fine for some apps but may be not be for others. I'm NOT saying we need to discuss this behaviour in the XML Encryption Syntax and Processing document if that is the general concensus, but I think it is worth pointing out at least on the list. And if the list discussion suggests that designers should have this point highlighted, we can add it to the spec. I'm not worried about the XML Encryption experts on this list grasping the issue but rather the impementors and integrators who will just be working with the spec. I would change the following "Consequently, in XML Encryption the specified transforms MUST be reversible. For instance, while an XSLT is an approriate transform in [XMLDSIG], it may not be in the encryption context because given a resulting document and the XSLT used to transform it, one can't necessarily obtain the source document. Also, note that these transforms do not affect the generation of CipherData, only representation at the designated URI." to --------------------- <heading>Reversibility (non-normative)</heading> Designers should note that because the same XML information set may have different binary or character encodings, applying even apparently straight-forward transforms that operate on the XML information set before encrypting will often change the XML surface string (eg. reordering an element's attributes). Consequently, the actual surface string that was encrypted may not be exactly, character-for-character, that in the pre-transformed source. For example, an XPath "//CreditCard" is used to extract nodes from an XML instance, these nodes are encrypted and replaced with <EncryptedData> elements. Because the XPath-extracted <CreditCard> elements may have had surface string changes, the decryption of the <EncryptedData> elements will result in <CreditCard> elements that have a different surface string than existed in the original source. Designers should note that the use of transforms that operate on the XML information set will often result in the decrypted version having a different XML surface string than existed in the original version. ----------------------- I look forward to your thoughts, Ed -- Original Message -- > >Reversibility of Transform operations from CipherReference has >absolutely nothing to do with getting back the original bits that were >entryped. These are transforms that are done to get the CIPHER >TEXT. Obviously, they can not have anything whatsoever to do with what >you get for plain text after decrypting. > >There can be Transform like operations performed before encryption and >after decryption. In fact, we recomment using C14N with comments >before encryption if it is desired to preserve the context. But such >Transform operations do not appear in CipherReference. > >Donald > >PS: If data being encrypted is binary or being treated as binary, >getting "the same bits back" makes sense. However, as you say, if data >is XML, getting the same bits back is meaningless. All applications >that conform to the XML 1.0 standard are required NOT to treat >anything they process as XML as a mere string of character codes or >logical characters. They are REQUIRED to treat it as a logically >structured entity in which certain "bits" in the octet string >representation (such as exact external coding of line terminations, >white space inside start and end tags, ordering of attributes) are >REQUIRED to be thrown away. > >From: edsimon@xmlsec.com >Message-ID: <3B23C10500001268@mail.san.yahoo.com> >Date: Tue, 12 Jun 2001 10:21:47 -0400 >In-Reply-To: <4.3.2.7.2.20010612085117.00b71508@localhost> >To: xml-encryption@w3.org > >>Ed wrote >>>>We're dropping the discussion of 'reversible transforms' from the spec >>so >>>>the last item is moot anyway. >>then Joseph wrote >>>BTW: I still thought a sentence or two was merited, so have a look at the >>> >>>most recent proposed edits I posted yesterday. >>>http://www.w3.org/Encryption/2001/05/11-proposal.html#sec-CipherReference >> >>Transforms must be completely reversible iff an application requires that >>the decrypted result be bit-by-bit or character-by-character exactly what >>was encrypted. In pre-XML encryption, it would generally be considered >>a problem if the post-decryption bits didn't exactly match the pre-encryption >>bits. However, in the brave new world of XML, some applications may not >>care if when >><element attr1='blah1' attr2="blah2" /> >>gets encrypted but the decrypted result is >><element attr2="blah2" attr1="blah1" /> >>or something else. >> >>On the other hand, some applications will want character-by-character and >>even bit-by-bit parity between the encrypted version and the decrypted version. >> These applications will have greater constraints on the types of transforms >>they can use because of the higher degree of reversibility required. >> >>I think XML Encryption is flexible enough to support the full ambit of reversibility >>requirements. I'm not arguing (at this point) for any requirements on the >>reversibility of transforms; I'm just using this posting as a way of thinking >>out loud and soliciting feedback from others. Jim and Don have already >>had some good points and I just want to make sure there is a good common >>understanding of this topic. >> >>Regards, Ed >> >> >> > >
Received on Tuesday, 12 June 2001 11:45:15 UTC