- From: <frederick.hirsch@nokia.com>
- Date: Mon, 23 Aug 2010 16:01:36 +0000
- To: Taki Kamiya <tkamiya@us.fujitsu.com>
- Cc: public-xmlsec@w3.org,<public-exi@w3.org>, <john.schneider@agiledelta.com>
Dear Taki Kamiya , The XML Security Working Group has reviewed the comments you sent [1] on the Last Call Working Draft [2] of the XML Encryption Syntax and Processing Version 1.1 published on 13 May 2010. Thank you for having taken the time to review the document and to send us comments! The Working Group's response to your comment is included below. Please review it carefully and let us know by email at public-xmlsec@w3.org if you agree with it or not before 13 Sept 2010. In case of disagreement, you are requested to provide a specific solution for or a path to a consensus with the Working Group. If such a consensus cannot be achieved, you will be given the opportunity to raise a formal objection which will then be reviewed by the Director during the transition of this document to the next stage in the W3C Recommendation Track. Thanks, For the XML Security Working Group, Thomas Roessler W3C Staff Contact 1. http://www.w3.org/mid/EEBCBA892F0D40A8B90EC0474D65F4AF@homunculus 2. http://www.w3.org/TR/2010/WD-xmlenc-core1-20100513/ ===== Your comment on 2.1.4 Encrypting Arbitrary Data and XML Documents If the ap...: > 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. Working Group Resolution (LC-2386): 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. ---- Your comment on 4.2 Well-known Type parameter values For interoperability p...: > 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. Working Group Resolution (LC-2387): "Unknown" means "unknown to the processor"; if this language was referring to a value not specified in this document, then we'd likely have chosen other language. Please let us know whether you think this requires further clarification. 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. ----
Received on Monday, 23 August 2010 16:01:43 UTC