Proposal for XML Encryption Last Call comments re EXI - ( LC-2386 LC-2387)

We need to follow up on the Last Call comment follow-up questions on XML Encryption 1.1 below.

Proposal to change XML Encryption 1.1 editors draft at  http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview.html#sec-eg-Arbitrary-Data

Proposal change from

[[
Where appropriate, such as in the case of encrypting an entire EXI stream, the Type attribute may be provided and the Mime type adjusted appropriately, 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'
   MimeType='application/exi'>
    <CipherData>
      <CipherValue>A23B45C56</CipherValue>
    </CipherData>
  </EncryptedData>
]]

to

[[
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>
]]

In addition I suggest adding a sentence to the end of the last paragraph in section 3.1, so it reads:

[[
MimeType is an optional (advisory) attribute which describes the media type of the data which has been encrypted. The value of this attribute is a string with values defined by [RFC2045]. For example, if the data that is encrypted is a base64 encoded PNG, the transferEncoding may be specified as 'http://www.w3.org/2000/09/xmldsig#base64' and the MimeType as 'image/png'. This attribute is purely advisory; no validation of the MimeType information is required and it does not indicate the encryption application must do any additional processing. Note, this information may not be necessary if it is already bound to the identifier in the Type attribute. For example, the Element and Content types defined in this specification are always UTF-8 encoded text. In the case of Type EXI the MimeType attribute is not necessary, but if used should reflect the underlying type and not "EXI".
]]

Does this change make sense and address the comment in the WG opinion?

regards, Frederick

Frederick Hirsch, Nokia
Chair XML Security WG



Begin forwarded message:

> From: ext Taki Kamiya <tkamiya@us.fujitsu.com>
> Date: September 13, 2010 10:00:32 PM EDT
> To: "public-xmlsec@w3.org" <public-xmlsec@w3.org>
> Cc: "Hirsch Frederick (Nokia-CIC/Boston)" <Frederick.Hirsch@nokia.com>, "public-exi@w3.org" <public-exi@w3.org>, "john.schneider@agiledelta.com" <john.schneider@agiledelta.com>
> Subject: 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, 26 October 2010 22:13:25 UTC