RE: Request for review: EXI integration with XML Encryption

Thomas,
 
On the behalf of the EXI working group, I want to thank you for giving us an
opportunity to review the latest editor's draft of XML Encryption 1.1. We
really appreciate the close collaboration between the EXI group and the
XMLSecurity group. 
 
We've completed our initial review of the referenced draft an included our
comments below. We hope they are useful. Please let s  know if you have
follow-up comments or questions. We wish you the best as you publish this
new working draft in the coming weeks!
 
    Best wishes!,
 
    John
 
----------- Detailed comments ----------------
 
Overall, we like the general approach of using the Type attribute of the
EncryptedData element to signal that the CypherText is encrypted EXI. This
is consistent with the XML Encryption processing model and seems like a very
reasonable insertion point of EXI. In the context of XML Encryption, we
don't believe the EXI data needs to be further qualified or restricted. This
proposed mechanism is sufficient.
 
We did have a few minor comments and suggestions regarding the integration
of EXI in the specification:

*	Section 3.1, description of "Type" attribute: 

The specification currently recommends the Type attribute be included when
the EncryptedData element contains an XML element or XML content. We would
also recommend the Type attribute also be included when the EncryptedData
element contains an EXI stream.


*	Section 4.1, second paragraph. For accuracy, we recommend this
paragraph be updated as follows:

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


*	Section 4.1, last paragraph: We recommend making this last paragraph
a little more specific. E.g.,: We could model this paragraph after the
equivalent XML paragraph, to read:

If XML Encryption is used with an EXI stream, then Encryptors and Decryptors
commonly perform type-specific processing. In particular, the encryptor will
replace the XML element or XML fragment in question with an appropriately
constructed EncryptedData element. The Decryptor will conversely replace the
EncryptedData element with its cleartext XML element or XML fragment. Note
that the XML document into which the EncryptedData element is embedded may
be encoded using EXI and/or EXI may be used to encode the cleartext before
encryption.


*	Section 4.4, bullet 2.1.

We recommend deleting the word "text" as the Cypher value may be encoded
using EXI.


*	Section 5.9. We had a question about this section.

Since we plan to define EXI canonicalization, should we include it here and
in the list in section 5.1 to maintain consistency with XML Canonicalization
2.0? Or would it be better to avoid references from Encryption 1.1 to
Canonicalization and Signatures 2.0? We don't need a formal response on
this. We just wanted to pose the question for your consideration.


*	Section A.1. 

We recommend you update the EXI URL to point to the latest version of the
EXI spec (http://www.w3.org/TR/exi/) or the CR version
(http://www.w3.org/TR/2009/CR-exi-20091208/).


  _____  

From: public-exi-request@w3.org [mailto:public-exi-request@w3.org] On Behalf
Of Thomas Roessler
Sent: Tuesday, February 23, 2010 1:15 AM
To: tkamiya@us.fujitsu.com; msc@mitre.org; Carine Bournez
Cc: Thomas Roessler; public-exi@w3.org; public-xmlsec@w3.org Public List
Subject: Request for review: EXI integration with XML Encryption


Hello, 

on behalf of the XML Security WG, I'd like to request initial review of
sections 4.1 through 4.4 of the XML Encryption 1.1 editor's draft; we are
looking toward publishing this material as a Working Draft during the next
two weeks and would like a sanity check on the basic approach.

To recap, that approach is:

- we define a Type parameter that indicates that the cleartext is, by
itself, an EXI stream.
- we say that user agents may do interesting stuff if that is the case
(including patching together things directly on the EXI level), but don't
specify any of this normatively.

Note that the spec defines distinct Type parameter values for cleartext that
follows the element or content productions from XML.  The reasons for that
distinction are lost in history, as we haven't been able to find an actual
difference in processing between the two; implementations seem to treat them
as identical.

http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview.src.html#sec-Pr
ocessing

(for tracker's benefit, this is ACTION-521)

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