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

Thank you very much Taki to you and the EXI WG.

I have marked the disposition of the EXI related Last Call comments on XML Encryption 1.1 as closed, see http://www.w3.org/2006/02/lc-comments-tracker/42458/WD-xmlenc-core1-20100513/doc/

For Tracker this completes ACTION-726

regards, Frederick

Frederick Hirsch, Nokia
Chair XML Security WG



On Dec 8, 2010, at 5:51 PM, ext Taki Kamiya wrote:

> Dear Frederick and XMLSEC members,
> 
> The EXI WG went over the changes relevant to our last comment in today's
> telecon, and unanimously concluded all the concerns we felt and reported
> have been well addressed in the update.
> 
> We appreciate XMLSEC's continuing attention to EXI, and would like to thank 
> the group for considering our comments, and took time to reflect that into
> the specification. 
> 
> Best regards,
> 
> Taki Kamiya for the EXI Working Group
> 
> 
> -----Original Message-----
> From: public-exi-request@w3.org [mailto:public-exi-request@w3.org] On Behalf Of Frederick.Hirsch@nokia.com
> Sent: Thursday, December 02, 2010 1:28 PM
> To: tkamiya@us.fujitsu.com
> Cc: Frederick.Hirsch@nokia.com; public-xmlsec@w3.org; public-exi@w3.org; john.schneider@agiledelta.com
> Subject: 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 Monday, 13 December 2010 20:51:40 UTC