Re: Request for review: EXI integration with XML Encryption

> 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.

Thanks, again; see answers below.

>>  
>> 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.

These changes are included in the latest editor's draft:
   http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview.src.html

>> 	•
>> 	• Section 4.4, bullet 2.1.
>> 
>> We recommend deleting the word "text" as the Cypher value may be encoded using EXI.

The value of CipherData is a base64 encoded octet stream.  "text" sounds like an appropriate word to apply to that to me.  I wonder what processing EXI applies to data like this?

>> 	• 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.

We are trying to keep the 1.1 work without dependency on the 2.0 work; therefore, I wouldn't expect additional notes about canonicalization in this spot.

(Your point that we need to catch up about use of EXI in the canonicalization role is well-taken, though.)

>> 	• 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/).

done

Received on Wednesday, 3 March 2010 23:32:54 UTC