- From: Thomas Roessler <tlr@w3.org>
- Date: Sun, 8 Aug 2010 17:09:09 +0200
- To: XMLSec WG Public List <public-xmlsec@w3.org>
- Cc: Thomas Roessler <tlr@w3.org>
Reviewing the comment, I propose that our answer is, roughly: 1. Handling an EXI stream as an octet-stream of media type application/exi is perfectly fine. In that case, one wouldn't want to use the EXI type parameter, and would not expect EXI-specific handling of the encryptor or decryptor to apply. 2. In section 4.2, "unknown" means "not known to the processor". We presumably could word-smith that point without further damage. 3. The mention of EXI in section 4.2 is intended to enable XML Encryption to be transparent as far as EXI is concerned. For example, an SVG image could be encoded with MimeType="application/svg+xml", and Type="EXI"; the encryption engine could return a parsed DOM tree (or whatever else makes sense) immediately. The signaling and intended processing of the two models is therefore *not* the same. Regards, -- Thomas Roessler, W3C <tlr@w3.org> (@roessler) Begin forwarded message: > From: <Frederick.Hirsch@nokia.com> > Date: 22 May 2010 15:08:59 GMT+02:00 > To: <tkamiya@us.fujitsu.com> > Cc: <Frederick.Hirsch@nokia.com>, <public-xmlsec@w3.org>, <public-exi@w3.org>, <john.schneider@agiledelta.com> > Subject: Re: Planning for EXI review of XML Encryption 1.1 Last Call > archived-at: <http://www.w3.org/mid/D2840A51-4117-4D80-9597-038008E555B5@nokia.com> > > 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 Sunday, 8 August 2010 15:09:13 UTC