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

Dear Frederick and XMLSEC members,

The EXI WG has reviewed the response [1] that the XML Security Working Group
provided as answers to our previous set of comments. We now better understand
the way EXI is integrated in the XML Encryption specification. We appreciate
the WG's continued efforts to bring the benefits of EXI to XML Security users.

Informed by the answers provided, the WG revisited the relevant parts of the
specification and has additional comments. We took a look at the document
currently available that is linked in the original reminder [2] of document
publication.

We see an example snippet of encrypted document in Section "2.1.4 Encrypting
Arbitrary Data and XML Documents" that uses EXI. We would like to suggest
to use a MimeType value other than "application/exi" in that particular
example. The example currently has both Type attribute of value
"http://www.w3.org/2009/xmlenc11#EXI" and MimeType attribute of value
"application/exi". This combination of values may be having the effect of
obscuring the merit of each attribute, which looks a bit at cross-purposes
with what was likely expected to be illustrated there. This is because when
a decipher does not know the Type "http://www.w3.org/2009/xmlenc11#EXI",
it is expected to convey both Type value and MIME-TYPE value to the application
along with the deciphered bytes as a blob. MIME-TYPE matters in this case
only when the application knows how to handle MIME-TYPE "application/exi" but
not Type value "http://www.w3.org/2009/xmlenc11#EXI" the condition of which we
believe will not be very common.

We therefore would like to see other more meaningful values to be used
for MimeType attribute in that example. For example, MimeType attribute value
"application/svg", when conveyed to the application, will indicate more
than what Type attribute can do, therefore, is one that can better serve
to articulate the significance of each attribute in the example.

Additionally, we would like to suggest to preamble the example by noting
that the MimeType attribute is optional. We would like to make sure that
people reading that part of the section do *not* end up having the impression
that MimeType attribute must accompany Type attribute when using EXI.
We expect that some use cases knowingly forgo MimeType attribute for EXI
because many EXI use cases try to conserve as much bandwidth as possible.

Best regards,

Taki Kamiya for the EXI Working Group


[1] http://lists.w3.org/Archives/Public/public-exi/2010Aug/0000.html
[2] http://lists.w3.org/Archives/Public/public-exi/2010May/0000.html


-----Original Message-----
From: frederick.hirsch@nokia.com [mailto:frederick.hirsch@nokia.com]
Sent: Monday, August 23, 2010 9:02 AM
To: Taki Kamiya
Cc: public-xmlsec@w3.org; public-exi@w3.org; john.schneider@agiledelta.com
Subject: Re: RE: Planning for EXI review of XML Encryption 1.1 Last Call ( LC-2386 LC-2387)


 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 Tuesday, 14 September 2010 02:02:57 UTC