RE: Updated XML Encryption 1.1 Editor's Draft

Review comments:

The concepts of "content" and "element" are also applicable to EXI.  EXI is really XML with a different encoding/serialization. (There are other binary encodings too, for example Oracle Database has binary xml encoding http://www.oracle.com/technology/products/database/oracle11g/pdf/xml-db-11g-whitepaper.pdf)  Many of the terms used like "fragment of an XML document", "XML processing"  are also applicable for EXI, but I think in this document they are meant to imply regular XML; we need to clarify them.

In both regular XML and EXI XML, it is possible to replace an Element by EncryptedData.

Ideally we should not use the Type attribute for representing EXI. Rather we should have a new XMLEncoding" attribute  which can take values like "Regular" (or maybe "Regular-UTF8")  and "EXI".  Type is orthogonal to XMLEncoding, i.e. it should be possible to have  both Type="element" and Type="content" along with XMLEncoding="EXI".   We had talked about this approach in the F2F and realized that we cannot do it, because it will break compatibility with the earlier processing model. So we have to use Type attribute to represent EXI.




Section 4.1
------------

*  "In the intended processing model, XML Encryption is used to encrypt either an octet-stream, or a fragment of an XML document that matches either the content or element production from [XML10]" 

Does "fragment of an XML document" also include fragment of an XML document with EXI serialization. Or are we saying that EXI follows the octet stream model?


* "If XML processing is handled inside the Encryptor and Decryptor, and the Type attribute values for element and content cleartext are used, then the Encryptor and Decryptor must ensure that the XML cleartext is serialized as UTF-8 before encryption, and -- if needed -- converted back to whatever other encoding might be used by the surrounding XML context"

Does "XML processing" here means that it is regular XML, not EXI XML?  Because from reading later down it is apparent that Type="element" or "content" is not used by EXI. The term "encoding" is also ambiguous - because EXI is also an encoding of XML, we should use the term "character-encoding".



* "Note that similar processing is also possible when the XML document that the EncryptedData element is embedded into is encoded using [EXI], or when [EXI] is used to encode the cleartext before encryption. "

This is not completely true,  because with the proposed model there is no way to distinguish between "element" and "content" in EXI, because we are using the Type attribute to denote it is EXI.


* Typo  "replae"  -> "replace"



Section 4.3
-----------
* "The cleartext data are assumed to be present as an octet stream. If the cleartext is of type element or content, the data must be serialized in UTF-8 as specified in [XML10], using Normal Form C [NFC]."

What does "cleartext" mean in "cleartext  is of type element or content". I would prefer to use the term "cleartext" only to mean the raw octets, and use the term "fragment of an XML document" to mean the XML that is being serialized into UTF-8 or into EXI.



Section 4.5
-----------
* "The application is responsible for the marshalling XML such that it can be serialized into an octet sequence, encrypted, decrypted, and be of use to the recipient."

The word "application" is currently in bold. In the previous version of the spec, "application" was referring to the three roles "application", "encryptor", "decryptor", but we have removed the application role now and using that term more loosely, so we should un-bold it.



Pratik



-----Original Message-----
From: Thomas Roessler [mailto:tlr@w3.org] 
Sent: Monday, January 25, 2010 3:07 PM
To: public-xmlsec@w3.org Public List
Cc: Thomas Roessler; Carine Bournez
Subject: Updated XML Encryption 1.1 Editor's Draft

Hello,

I've done some serious editing to the XML Encryption 1.1 editor's draft.

The version now checked in here:
  http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview.html

... includes:

- separation between intended processing model and core processing model (at the same time reducing the fluff that had previously been present; section 4)
- optional EXI support
- fixes to the pieces surrounding schema and namespaces

This should take care of: 

- ACTION-500 (update namespace section)
- ACTION-473 (update processing)

(I have no doubt that section 4 needs serious review, and probably has a few bugs.)

Regards,
--
Thomas Roessler, W3C  <tlr@w3.org>

Received on Thursday, 28 January 2010 22:06:47 UTC