RE: RE: Draft Minutes from 010611 Teleconf (changes)

In section 3.2.1 of the current draft, would you agree to replacing everything
from "The syntax of the URI and Transforms is similar to ..." up to (but
not including) the schema definition with this text:

--- start ---
Though the syntax of the Transforms is based on that in XML Signature [XMLDSIG],
the purpose for transforms in XML Encryption's <CipherReference> element
is unrelated to their purpose in XML Signature's <Reference> element.  In
XML Signature, transforms are used to select or exclude data to be secured;
in XML Encryption, transforms are used solely to obtain the cipherdata that
will be decrypted into an XML string and inserted in place of the <EncryptedData>
element.
--- end ---

Ed

-- Original Message --

>Ed,
>
>I must respectfully disagree with you on this.  I find this whole
>discussion of transform reversibility to be confusing and largely
>irrelevant and prefer Don's suggested wording.  Specifically, your
>statement 
>
>	"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 ..."
>
>is wrong in this context.  What you get after decrypting the cipher text
>is precisely bit-for-bit the octet sequence that was encrypted.  The
>fact that the encryptor may have obtained the to-be-encrypted octet
>sequence based on some serialization of XML, that may differ from other
>possible serializations, doesn't matter.  All you're really saying is
>that there are multiple ways one may serialize XML and it is generally
>impossible to reverse the process to obtain some earlier serialized
>representation.  There is nothing encryption specific about this issue.
>
>Blair
>
>
>-----Original Message-----
>From: edsimon@xmlsec.com [mailto:edsimon@xmlsec.com] 
>Sent: Tuesday, June 12, 2001 8:45 AM
>To: xml-encryption@w3.org
>Subject: Re: RE: Draft Minutes from 010611 Teleconf (changes) 
>
>
>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-CipherRefer
>>>>ence
>>>
>>>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 16:11:24 UTC