There are 7 comments (sorted by their types, and the section they are about).
question comments
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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Frederick Hirsch
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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 .