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

Dear Taki and EXI WG members:

The WG reviewed your additional comments sent 13 September 2010 (see below) and made changes to address them along the lines you suggested [1][2].

Specifically, in section 2.1.4 we removed the MimeType attribute from the example, and added text before the example that this attribute is optional and should reflect the underlying type.

[[
Where appropriate, such as in the case of encrypting an entire EXI stream, the Type attribute should be provided and indicate the use of EXI. The optional MimeType may be used to record the actual (non-EXI-encoded) type, but is not necessary and may be omitted, as in the following EXI encryption example:

  <?xml version='1.0'?> 
  <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
   Type='http://www.w3.org/2009/xmlenc11#EXI'>
    <CipherData>
      <CipherValue>A23B45C56</CipherValue>
    </CipherData>
  </EncryptedData>
]]

We also added a sentence to "3.1 The EncryptedType Element" to clarify this as well, 

[[
In the case of Type EXI the MimeType attribute is not necessary, but if used should reflect the underlying type and not "EXI".
]]

We believe this addresses your concerns and that your original Last Call comments as well as these additional comments can now be considered resolved and the corresponding issue(s) closed.

The latest published Last Call draft  published 30 November reflects these changes, please see http://www.w3.org/TR/2010/WD-xmlenc-core1-20101130/

Please respond to this email indicating whether you agree that this is resolved, so that we can close the issue.

Thank you

regards, Frederick

Frederick Hirsch, Nokia
Chair XML Security WG

[1] http://lists.w3.org/Archives/Public/public-xmlsec/2010Oct/0045.html

[2] http://lists.w3.org/Archives/Public/public-xmlsec/2010Nov/att-0015/minutes-2010-11-02.html#item07

For tracker, this message is related to ACTION-726

On Sep 13, 2010, at 10:00 PM, ext Taki Kamiya wrote:

> 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 Thursday, 2 December 2010 21:30:42 UTC