W3C home > Mailing lists > Public > public-exi@w3.org > May 2010

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

From: <Frederick.Hirsch@nokia.com>
Date: Sat, 22 May 2010 15:08:59 +0200
To: <tkamiya@us.fujitsu.com>
CC: <Frederick.Hirsch@nokia.com>, <public-xmlsec@w3.org>, <public-exi@w3.org>, <john.schneider@agiledelta.com>
Message-ID: <D2840A51-4117-4D80-9597-038008E555B5@nokia.com>

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 


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


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:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:47:15 UTC