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

Re: RE: Planning for EXI review of XML Encryption 1.1 Last Call ( LC-2386 LC-2387)

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>
Message-Id: <E1OnZSq-000708-RU@jessica.w3.org>

 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:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 23 August 2010 16:01:42 GMT