Disposition of comments for the XML Security Working Group

Single page view

In the table below, red is in the WG decision column indicates that the Working Group didn't agree with the comment, green indicates that a it agreed with it, and yellow reflects an in-between situation.

In the "Commentor reply" column, red indicates the commenter objected to the WG resolution, green indicates approval, and yellow means the commenter didn't respond to the request for feedback.

Commentor	Comment	Working Group decision	Commentor reply
LC-2543 MURATA Makoto `<eb2m-mrt@asahi-net.or.jp>` (archived comment)	Is the definition of PRFAlgorithmIdentifierType correct? In my understanding, it prohibits Parameters elements. oXygen (and probably Xerces) agrees with me.	The WG agrees with the interpretation that PRFAlgorithmIdentifierType prohibits Parameters elements. The WG also agreed and updated the schema and specification to add type="anyURI" to AlgorithmIdentifierType for the Algorithm attribute, resulting in the following updated definition: <complexType name="AlgorithmIdentifierType"> <sequence> <element name="Parameters" minOccurs="0"/> </sequence> <attribute name="Algorithm" type="anyURI"/> </complexType>	yes
LC-2544 MURATA Makoto `<eb2m-mrt@asahi-net.or.jp>` (archived comment)	xenc-schema-11.xsd does not import xmldsig11-schema.xsd but rather import xmldsigschema.xsd. However, XML Encryption 1.1 normatively references to XML Signature 1.1 rather than 1.0. Which is correct?	The working group decided to not make any change here as xenc-schema-11.xsd does not require any definitions from xmldsig-11-schema.xsd. All that is required is ds:DigestMethod from xmldsigschmema.xsd; so the current inclusion is correct and does not include unnecessary material. Thus the schema import is correct as is the normative reference to XML SIgnature 1.1 (e.g. to pick up normative changes that are not necessarily reflected by schema changes) The file gh-example.xml in generic-hybrid-ciphers was corrected; the associated specification was already correct.	yes
LC-2387 Taki Kamiya `<tkamiya@us.fujitsu.com>` on behalf of EXI Working Group (archived comment)	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.	"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.	yes
LC-2420 Thomas Roessler `<tlr@w3.org>` (archived comment)	The example in section 2.2.1 is broken: [s1] <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' Type='http://www.w3.org/2001/04/xmlenc#Element'/> The closing slash is one too many. http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/#sec-eg-Symmetric-Key Regards, -- Thomas Roessler, W3C <tlr@w3.org> (@roessler)	Slash removed, correcting error, see http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0073.html	yes
LC-2541 MURATA Makoto `<eb2m-mrt@asahi-net.or.jp>` (archived comment)	XML Encryption Syntax and Processing Version 1.1 references to itself as a normative reference.	Updated XML Encryption 1.1 to change "[XMLENC-CORE1]" to "(XMLENC-CORE1, this document)" in the media type section of XML Encryption 1.1 to avoid generating normative self reference. There is now no reference to the document itself as a normative reference.	yes
LC-2542 MURATA Makoto `<eb2m-mrt@asahi-net.or.jp>` (archived comment)	I do not understand the note: Note that the same URI is used to identify base64 both in "encoding" context (e.g. when needed within a CipherValue element) as well as in "transform" context (when identifying a base64 transform)." in XML Encryption 1.1. The CipherValue element does not have the Algorithm attribute. Why can the URI http://www.w3.org/2000/09/xmldsig#base64 be used for encoding?	changed the base64 note in the algorithms section (section 5) from [[ note: Note that the same URI is used to identify base64 both in "encoding" context (e.g. when needed within a CipherValue element) as well as in "transform" context (when identifying a base64 transform) ]] to [[ note: The same URI is used to identify base64 both in "encoding" context (e.g. when used with the Encoding attribute of an EncryptedKey element, see section 3.1 The EncryptedType Element<file:///Materials/Builds/xmlsec2/Drafts/xmlenc-core-11/Overview.src.html#sec-EncryptedType>) as well as in "transform" context (when identifying a base64 transform for a CipherReference, see section 3.3.1 The CipherReference Element<file:///Materials/Builds/xmlsec2/Drafts/xmlenc-core-11/Overview.src.html#sec-CipherReference>). ]] http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview.html#base64note For visibility I also added the following to the end of section 3.1: [[ Encoding is an optional (advisory) attribute which describes the transfer encoding of the data that has been encrypted. ]] (the previous MimeType paragraph outlines its use in conjunction with MimeType and gives base64 as an example) http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview.html#sec-EncryptedType see http://lists.w3.org/Archives/Public/public-xmlsec/2011Aug/0066.html	yes
LC-2386 Taki Kamiya `<tkamiya@us.fujitsu.com>` on behalf of EXI Working Group (archived comment)	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.	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.	yes