Re: Planning for EXI review of XML Encryption 1.1 Last Call

Taki

Thanks to you and EXI WG for your timely comments.

I have added these comments to our Last Call comment tracker and will add them the XML Security agenda for discussion 

<http://www.w3.org/2006/02/lc-comments-tracker/42458/WD-xmlenc-core1-20100513/>

XML Security WG members, please review these comments and discuss on the public list.

Thanks

regards, Frederick

Frederick Hirsch, Nokia
Chair XML Security WG



On May 19, 2010, at 6:14 PM, ext Taki Kamiya wrote:

> Dear Frederick and XMLSEC members,
> 
> Thank you for having heralded us of the upcoming release of drafts, which allowed
> us to initiate the review in a timely fashion.
> 
> Please find below is our initial set of comments and questions regarding the XML
> Encryption working draft [1]. We may have additional comments and questions,
> and will send them out in separate emails when we have any and they become
> ready.
> 
> Best regards,
> 
> Taki Kamiya for the EXI Working Group
> 
> ------
> 
> Section 2.1.4 "Encrypting Arbitrary Data and XML Documents" defines a way to
> encrypt a document as a whole, and shows an example that demonstrates the
> ability to encode a whole XML document. A natural corollary would be encrypting
> the whole EXI stream, with MimeType="application/exi", which may not necessarily
> be stated there, however, I would like to confirm that such use of EXI within
> EncryptedData is both legal and within the expectation of the WG.
> 
> Section 4.2 "Well-known Type parameter values" defines a reserved value for EXI.
> It also states that:
> "Encryptors and Decryptors should handle unknown or empty Type attribute values
> as a signal that the cleartext is to be handled as an opaque octet-stream,
> whose specific processing is up to the invoking application. In this case, the
> Type, MimeType and Encoding parameters should be treated as opaque data whose
> appropriate processing is up to the application."
> 
> It is not clear to me what is expected of a processor that does not implement
> EXI have encountered Type value of "http://www.w3.org/2009/xmlenc11#EXI".
> Since the value "http://www.w3.org/2009/xmlenc11#EXI" is well-known, the quoted
> paragraph does not seem to apply to the value.
> 
> When I think that the encryption of EXI stream as a whole is covered by section
> 2.1.4, I start to wonder what the mention of EXI in section 4.2 would add beyond
> that in terms of function. It appears as though the two mechanisms are
> functionally same with regards to how they relate to EXI, since both provide
> ways to encrypt and contain EXI streams within XML.
> 
> [1] http://www.w3.org/TR/2010/WD-xmlenc-core1-20100513/
> 
> 
> -taki
> 
> 
> -----Original Message-----
> From: Frederick Hirsch [mailto:frederick.hirsch@nokia.com]
> Sent: Monday, May 03, 2010 10:26 AM
> To: john.schneider@agiledelta.com Schneider; Taki Kamiya
> Cc: Frederick Hirsch; msc@mitre.org Cokus; Carine Bournez; public-exi@w3.org; public-xmlsec@w3.org Public List; ext Thomas Roessler
> Subject: Planning for EXI review of XML Encryption 1.1 Last Call
> 
> John, Taki
> 
> The XML Security WG anticipates bringing  XML Encryption 1.1 [1] and
> Generic Hybrid Ciphers  [2] to Last Call in the near future, as well
> as having a short Last Call for an added feature to XML Signature 1.1
> [3].
> 
> EXI is specifically mentioned in XML Encryption 1.1 in Section  3.1
> "The EncryptedType Element", 4.1 "Intended Application Model", 4.2
> "Well-known Type parameter values" and in the References.
> 
> We would like EXI review of the drafts, in particular the material
> related to EXI. Would a 4 week Last Call period be sufficient, say
> starting on 13 May and running until 10 June?
> 
> Thanks
> 
> regards, Frederick
> 
> Frederick Hirsch
> Nokia
> 
> [1] <http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview.htm>
> 
> [2] <http://www.w3.org/2008/xmlsec/Drafts/generic-hybrid-ciphers/Overview.html
>> 
> 
> [3] KeyInfoReference, section 4.5.10 <http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-KeyInfoReference
>> 
>

Received on Saturday, 22 May 2010 13:10:30 UTC