Re: Request for review: EXI integration with XML Encryption

Thanks, John.

These changes look consistent with the intent of what we were planning to do. I'll incorporate them into the editor's draft and let them sit till the next WG meeting.  FYI, we're currently planning to publish a new working draft of encryptoin 1.1 on 16 March.

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







On 3 Mar 2010, at 20:55, John Schneider wrote:

> 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-Processing
> 
> (for tracker's benefit, this is ACTION-521)
> 
> Thanks,
> --
> Thomas Roessler, W3C  <tlr@w3.org>
> 
> 
> 
> 
> 
> 
>