Re: Request for review: EXI integration with XML Encryption

John, Taki

Thanks to you both and the EXI WG for working with the XML Security  
WG, it has been very helpful.

Thomas,

I assume you mean that you will incorporate these changes into the  
current editors draft that will be then used to publish on 16 March?
Will you do that edit before our call next week?

The WG can discuss this on our call this coming Tuesday 9 March - I'll  
add to the agenda.

regards, Frederick

Frederick Hirsch, Nokia
Chair XML Security WG



On Mar 3, 2010, at 4:31 PM, ext Thomas Roessler wrote:

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

Received on Wednesday, 3 March 2010 21:45:21 UTC