There are 6 comments (sorted by their types, and the section they are about).
substantive comments
Comment LC-2371
Commenter: Scott Cantor <cantor.2@osu.edu> (archived message ) Context: 4.5.3 The RetrievalMethod Element (Add new section 4.5.10 for KeyInfoReference, update schema)
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 :During the Requirements Workshop that led to the 1.1 effort, some flaws in
the schema and their impact on the ds:RetrievalMethod element were
discussed. With the inability to change the schema, an alternative approach
had to be developed to fix the problems with RetrievalMethod and the
assumption had been that the solution would require changes coming in XML
Signature 2.0.
After examining the problem and working up a solution, it turns out to be
compatible with XML Signature 1.1 as a KeyInfo child element extension, and
I believe it should be incorporated into 1.1 before final approval. The
addition is small, and low risk.
I propose the following additional section to be added as 4.5.10, and the
additional schema content added to the 1.1 extension schema. (We may wish to
adjust the warning text in section 4.5.3 about the use of RetrievalMethod to
recommend the use of KeyInfoReference in its place, but this is optional.)
------
The KeyInfoReference Element
A KeyInfoReference element within KeyInfo is used to convey a reference to a
KeyInfo element at another location in the same or different document. For
example, several signatures in a document might use a key verified by an
X.509v3 certificate chain appearing once in the document or remotely outside
the document; each signature's KeyInfo can reference this chain using a
single KeyInfoReference element instead of including the entire chain with a
sequence of X509Certificate elements repeated in multiple places.
KeyInfoReference uses the same syntax and dereferencing behavior as
Reference's URI (section 4.4.3.1) and the Reference Processing Model
(section 4.4.3.2) except that there are no child elements and the presence
of the URI attribute is mandatory.
The result of dereferencing a KeyInfoReference MUST be a KeyInfo element, or
an XML document with a KeyInfo element as the root.
Note: The KeyInfoReference element is a desirable alternative to the use of
RetrievalMethod when the data being referred to is a KeyInfo element and the
use of RetrievalMethod would require one or more Transform child elements,
which introduce security risk and implementation challenges.
Schema Definition
<!-- targetNamespace="http://www.w3.org/2009/xmldsig11#" -->
<element name="KeyInfoReference" type="dsig11:KeyInfoReferenceType"/>
<complexType name="KeyInfoReferenceType">
<attribute name="URI" type="anyURI" use="required"/>
<attribute name="Id" type="ID" use="optional"/>
</complexType>
Related issues: ISSUE-187
(space separated ids)
WG Notes: ISSUE-187 Last Call Issue - Retrieval Method schema and usability
Update completed: http://lists.w3.org/Archives/Public/public-xmlsec/2010Feb/0034.html
with review corrections http://lists.w3.org/Archives/Public/public-xmlsec/2010Feb/0040.html
Resolution: RESOLUTION: WG agrees to KeyInfoReference proposal from Scott, removing Type, allowing continued use of RetrievalMethod for other purposes, and referencing Reference for URI processing
http://www.w3.org/2010/02/09-xmlsec-minutes.html#item06
also to be clear for 1.1:
RESOLUTION: Accept proposed Last Call change in http://lists.w3.org/Archives/Public/public-xmlsec/2010Feb/0019.html
http://www.w3.org/2010/02/16-xmlsec-minutes.html#item07 (Please make sure the resolution is adapted for public consumption)
Comment LC-2424
Commenter: Scott Cantor <cantor.2@osu.edu> (archived message ) Context: 4.5.4 The X509Data Element
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Scott Cantor
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 :Due to the ongoing problems with the X509IssuerSerial element, I would ask
that a new X509Data alternative for representing certificates uniquely by
hash be added to the 1.1 schema and specification, per the suggested changes
here:
http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0052.html
Related issues: (space separated ids)
WG Notes: ACTION-675 to incorporate change in 2.0 as well.
Resolution: RESOLUTION: group accepts scantor's proposal, to change both 1.1 and 2.0 specifications
http://www.w3.org/2010/09/28-xmlsec-minutes.html#item05
Updated XML SIgnature 1.1 draft, schema and RELAX NG Schema. (Please make sure the resolution is adapted for public consumption)
Comment LC-2368
Commenter: Frederick Hirsch <frederick.hirsch@nokia.com> (archived message ) Context: 4.5.8 XML Encryption EncryptedKey and Agreement Elements
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 :ISSUE-188: Agreement referenced in XML Signature 1.1 but definition not clear [Sig11 (XML Signature 1.1)]
http://www.w3.org/2008/xmlsec/track/issues/188
Raised by: Frederick Hirsch
On product: Sig11 (XML Signature 1.1)
Issue: xenc:Agreement referenced by XML Signature 1.1 does not appear to be defined.
XML Signature 1.1 section 4.5.8, http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-keyconvenance
states:
"The <xenc:EncryptedKey> and <xenc:Agreement> elements defined in [XMLENC-CORE1] as children of ds:KeyInfo can be used to convey in-band key agreement information, or encrypted key material."
xenc:Agreement does not appear in XML Encryption 1.1 or in the XML Encryption schema?
also referenced in section 4.5, KeyInfo schema.
http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-KeyInfo
Proposal:
Change references from xenc:Agreement to enc:DerivedKey in XML Signature 1.1
Related issues: ISSUE-188
(space separated ids)
WG Notes: ISSUE-188 Agreement referenced in XML Signature 1.1 but definition not clear
Resolution: Change xenc:Agreement changed to enc:DerivedKey in XML Signature 1.1 as proposed in
http://lists.w3.org/Archives/Public/public-xmlsec/2010Mar/0001.html
The WG adopted the following resolution:
RESOLUTION: Accept change to XML Signature 1.1 for ISSUE-188 as distributed by Magnus in message 1 of March 2010.
Minuted at http://www.w3.org/2010/03/02-xmlsec-minutes.html#item07 (Please make sure the resolution is adapted for public consumption)
Comment LC-2376
Commenter: MURATA Makoto (FAMILY Given) <eb2m-mrt@asahi-net.or.jp> (archived message ) Context: 6.1 Algorithm Identifiers and Implementation Requirements
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 :http://lists.w3.org/Archives/Public/public-xmlsec/2010Mar/0052.html
Which is correct?
http://www.w3.org/2001/04/xmlenc#sha384 (in XML Signature 1.1)
http://www.w3.org/2001/04/xmldsig-more#sha384 (in XML Encryption 1.1)
Do they refer to different algorithms?
---
http://lists.w3.org/Archives/Public/public-xmlsec/2010Mar/0029.html
Also,
In 6.1, the URI is
http://www.w3.org/2001/04/xmldsig-more#sha384
In 6.2.3, the URI is
http://www.w3.org/2000/09/xmldsig#sha384
Which is correct? Or, are they different?
Related issues: ISSUE-190,
ISSUE-191
(space separated ids)
WG Notes: Use http://www.w3.org/2001/04/xmldsig-more#sha384
Resolution: http://lists.w3.org/Archives/Public/public-xmlsec/2010Mar/0074.html
RESOLUTION: use http://www.w3.org/2001/04/xmldsig-more#sha384 for backward compatibility
Minutes: http://www.w3.org/2010/03/09-xmlsec-minutes.html#item03 (Please make sure the resolution is adapted for public consumption)
Comment LC-2390
Commenter: Scott Cantor <cantor.2@osu.edu> (archived message ) Context: 9.1 XSD Schema
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 :Just reviewing the schema and noted there's a redundancy:
<simpleType name="ECPointType">
<restriction base="ds:CryptoBinary"/>
</simpleType>
Other places in the EC key syntax schema just use CryptoBinary directly, so
I'd suggest removing that type definition and
s/dsig11:ECPointType/ds:CryptoBinary for consistency.
This shouldn't affect any implementations at this point.
Related issues: (space separated ids)
WG Notes: The WG discussed this on 15 June, http://www.w3.org/2010/06/15-xmlsec-minutes.html#item04
WG members noted that the reason for the different type is to highlight different semantics and processing rules. In particular CryptoBinary retains leading 0's (unlike Base64) and ECPointType is two points in one binary representation, and could possibly have compression. This is the rationale for a new type and this approach is already in use.
Resolution: RESOLUTION: No change needed for LC-2390, Schema Redundancy last call issue (Please make sure the resolution is adapted for public consumption)
Add a comment .