RE: Request for review: EXI integration with XML Encryption

Thomas,

Thank you very much for the quick turn-around on these items. The updated
version looks great.

Below are responses to your question and comment:

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

EXI encodes binary data declared as base64Binary in its original binary form
(i.e., a binary octet stream). It does not require conversion to or from
base64 text. So in cases where the enclosing document is encoded using EXI,
the cypherdata will be represented in its original binary form rather than
base64 text.  Regardless, this is really a very minor point and I think this
part of the document is fine as it is.

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

Sounds great. That's kind-of what we figured, but we thought we'd ask just
in case.

Thanks again for your quick attention to our comments. We look forward to
our continued work together!

	Best wishes,

	John

> -----Original Message-----
> From: public-exi-request@w3.org 
> [mailto:public-exi-request@w3.org] On Behalf Of Thomas Roessler
> Sent: Wednesday, March 03, 2010 3:33 PM
> To: john.schneider@agiledelta.com Schneider; 
> tkamiya@us.fujitsu.com; msc@mitre.org; Carine Bournez; 
> public-exi@w3.org; public-xmlsec@w3.org Public List
> Subject: 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 Thursday, 4 March 2010 16:52:37 UTC