List of comments on “XML Encryption Syntax and Processing Version 1.1” (dated 13 May 2010)

There are 7 comments (sorted by their types, and the section they are about).

question comments

Comment LC-2386: Commenter: Taki Kamiya <tkamiya@us.fujitsu.com> on behalf of EXI Working Group (archived message); Context: 2.1.4 Encrypting Arbitrary Data and XML Documents If the ap...; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; 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.; Related issues: (space separated ids); WG Notes: The XML Security WG agreed to the proposed resolution on the comment at the teleconference held on 10 August, see http://www.w3.org/2010/08/10-xmlsec-minutes.html#item04 .; Resolution: 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.; (Please make sure the resolution is adapted for public consumption)

substantive comments

Comment LC-2420: Commenter: Thomas Roessler <tlr@w3.org> (archived message); Context: 2.2.1 EncryptedData with Symmetric Key (KeyName) [s1] <E...; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; 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); Related issues: (space separated ids); WG Notes:; Resolution: Slash removed, correcting error, see http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0073.html; (Please make sure the resolution is adapted for public consumption)

Comment LC-2387: Commenter: Taki Kamiya <tkamiya@us.fujitsu.com> on behalf of EXI Working Group (archived message); Context: 4.2 Well-known Type parameter values For interoperability p...; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; 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.; Related issues: (space separated ids); WG Notes: The XML Security WG agreed to the proposed resolution on the comment at the teleconference held on 10 August, see http://www.w3.org/2010/08/10-xmlsec-minutes.html#item04 .; Resolution: "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.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2543: Commenter: MURATA Makoto <eb2m-mrt@asahi-net.or.jp> (archived message); Context: 5.4.2 PBKDF2 Identifier: http://www.w3.org/2009/xmlenc11#p...; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Is the definition of PRFAlgorithmIdentifierType correct?
In my understanding, it prohibits Parameters elements.
oXygen (and probably Xerces) agrees with me.; Related issues: (space separated ids); WG Notes: Comment during CR Discussion http://lists.w3.org/Archives/Public/public-xmlsec/2011Aug/0028.html; Resolution: 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>; (Please make sure the resolution is adapted for public consumption)

Comment LC-2544: Commenter: MURATA Makoto <eb2m-mrt@asahi-net.or.jp> (archived message); Context: 9.1 XSD Schema XML Encryption Core Schema Instance xenc-sc...; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; 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?; Related issues: (space separated ids); WG Notes:; Resolution: 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.; (Please make sure the resolution is adapted for public consumption)

editorial comments

Comment LC-2542: Commenter: MURATA Makoto <eb2m-mrt@asahi-net.or.jp> (archived message); Context: 5.1.1 Table of Algorithms The table below lists the categor... (note regarding base64 URI); Status:
assigned to Frederick Hirsch; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; 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?; Related issues: (space separated ids); WG Notes: Comment during CR Explanation and proposed changes - http://lists.w3.org/Archives/Public/public-xmlsec/2011Aug/0027.html; Resolution: 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; (Please make sure the resolution is adapted for public consumption)

Comment LC-2541: Commenter: MURATA Makoto <eb2m-mrt@asahi-net.or.jp> (archived message); Context: [XMLENC-CORE1] (Section 8 has reference to XML Encryption 1.1 itself); Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
XML Encryption Syntax and Processing Version 1.1 references to itself
as a normative reference.; Related issues: (space separated ids); WG Notes: Discussion/explanation and proposed change: http://lists.w3.org/Archives/Public/public-xmlsec/2011Aug/0026.html; Resolution: 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.; (Please make sure the resolution is adapted for public consumption)

Add a comment.

Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: index.html,v 1.1 2017/08/11 06:45:30 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org