This page enumerates outstanding issues on the XML
Key Management Specification. The source of an issue need not be its first
instance; it also might reference a cogent description or WG poll. Also, this
document may not capture editorial tweaks and errors that were easily and
quickly remedied.
This page will contain two tables. Outstanding issues are recorded in
the first table. They are typed as either Editorial (including typos and
small clarifications), Clarification (where significant explanatory text
is required) or Major. In some cases, a volunteer has been
identified, but in case not, then implementation of the proposed resolution is
left to the specification editor(s). Once an issue has been resolved
(meaning that a resolution satisfactory to the group is agreed and has been
included in the latest version of the specification), the issue is moved to the
`Resolved Issues' table. The issue index number is maintained to allow for
consistent referencing.
New issues, and the resolution of issues should be reported to the XKMS
mailing list. Before doing so, ensure that the issue is not already covered
by an issue either in the "Outstanding Issues" table (in which case, a
new issue need not be entered) or in the "Resolved Issues" table (in
which case a new outstanding issue should be created, as opposed to moved from
resolved to outstanding). In addition, for newly discovered issues, the
discoverer should identify an related issues that may already be cited in either
table below.
Last Minute Issues
# |
Type & Source |
Specification Reference & Issue Description |
Proposed Resolution Details (incl Date)& Volunteer (Specification editor(s) if blank) |
37 |
Editorial/ [ Sept 2002 F2F] |
[Part
I - 2002/08/01] [Part
II - 2002/08/01] The "Status of this Document" section needs to be brought up-to-date. |
Makes appropriate changes to this section at final draft (see also Issue 35). [ Sept 2002 F2F] |
39 |
Editorial/ [ Sept 2002 F2F] |
[Part
I - 2002/08/01] [Part
II - 2002/08/01] In paragraph [1], the glyphs for (C) and TM are missing. |
Add appropriate glyphs. [ Sept 2002 F2F] |
17 |
Clarification/ [ Sept 2002 F2F] |
[Part
I - 2002/08/01] [Part
II - 2002/08/01] The specification should be validated against the requirements [XKMS Requirements]. |
Ensure that this validation is performed
prior to moving through Working Group Last Call. [ Sept
2002 F2F]. Frederick Hirsch |
Examples Issues
# |
Type & Source |
Specification Reference & Issue Description |
Proposed Resolution Details (incl Date)& Volunteer (Specification editor(s) if blank) |
47 |
Clarification/ [ Sept 2002 F2F] |
[Part
I - 2002/08/01] [Part
II - 2002/08/01] Some remaining issues with examples, in particular the canonicalization of the signature block may be incorrect, the certificates presented bear no relation to the public keys allegedly certified. |
Make changes/updates as described. Brian
LaMacchia will provide some code for X.509 examples.[ Sept
2002 F2F] Phill Hallam-Baker, Brian LaMacchia |
123 | Clarification/Ed Simon/ [List email - 12/05/2002] | Proposed changes regarding use of exclusive canonicalization. | |
201 | Shivram http://lists.w3.org/Archives/Public/www-xkms/2003Feb/0022.html |
Line 90 /Section 4.6 still needs work | Currently coding |
210 | Frederick http://lists.w3.org/Archives/Public/www-xkms/2003Feb/0024.html |
PT2 [90] ISSUE Compound
request example TBS - not sure it is needed given part 1 text. |
|
204 | Reagle http://lists.w3.org/Archives/Public/www-xkms/2003Feb/0027.html |
[78]
The example in 3.1 still doesn't reflect if in fact that things are QNAMEs yet. |
Stated explicitly that QNames are not prefixed in the running text. |
205 | Reagle http://lists.w3.org/Archives/Public/www-xkms/2003Feb/0027.html |
[94] I don't understand, are the ResultMinor
Codes, QNAMEs? If so, are they expect to be composed with a ResultMajor code? If so, I wouldn't think the code is "Success.NoMatch" but a QNAME tuple (xkms:Success,xkms:NoMatch) or some composition "xkms:Success.NoMatch". |
|
98 | clarification | Add in policy identifier into example 5.1.1 to allow alice to specify the registrationpolicy she wants to the registered under (see issue 49) | Text fixed, fix code |
Other, possibly fixed issues:
# |
Type & Source |
Specification Reference & Issue Description |
Proposed Resolution Details (incl Date)& Volunteer (Specification editor(s) if blank) |
118 | Major/Slava Galperin/ [List email - 12/11/2002] | Address a potential request substitution vulnerability stemming from the fact that XKRSS request type is not part of the signature scope of KeyBindingAuthentication which allows one to transform certain forms of ReissueRequest, RevokeRequest and RecoverRequest into each other (see see [List email - 11/20/2002] (3.35)) | DONE, created an element of KeyBinding type for each operation. |
122 | Clarification/Frederick Hirsch/ [List email - 12/05/2002] | Is it possible to use XKMS to manage SSL client
certificate validation? If so I have a question about the UseKeyWith
Identifier semantics. Upon registration, I assume I would
- not specify KeyUsage (since it really isn't for signing or encryption per se) - and would not know how to use UseKeyWith because the SSL UseKeyWith Application assumes a server side identifier. I would like to limit the client certificate to SSL only. How can I do this? (I realize that this is not a ds:KeyInfo application, but am thinking how an XKMS server would be beneficial beyond XML security applications) |
The KeyUsage is Exchange, the UseKeyWith is as specified for the undelying protocl. |
115 | Major/Merlin Hughes [List email - 12/12/2002] | Proposed modification to former XBULK status requests and responses. | Done - incomplete see successor issues above |
116 | Major/Slava Galperin [List email - 12/11/2002] | More connective stuff is needed to explain ID model for KeyBinding (see [List email - 11/20/2002] (2.29,3.31, 3.33, 3.38)) For example, I am still unclear if one can use ID as a stable identifier for a distinct persistent KeyBinding object or is it just a transient message-scoped value used just to reference XML element from a signature block of the same protocol message. I am afraid that different implementations may end up assuming different interpretations which will impede interoperability. | |
117 | Major/Slava Galperin/ [List email - 12/11/2002] | Define matching rules for <QueryKeyBinding> when multiple <UseKeyWith> or <PolicyIdentifier>or <KeyUsage> are used (see see [List email - 11/20/2002] (2.20,2.30)) | |
119 | Editorial/Frederick Hirsch/ [List email - 12/05/2002] | In RequestAbstractType the attribute OriginalRequestId has type IDREF. (line [71] Isn't IDREF only applicable for id's specified elsewhere in the same document, and isn't this attribute referring to an id specified in an earlier message? Should this be anyURI? I also notice this for ResultAbstractType at [89] | Phill to change to anyURI. |
120 | Editorial/Frederick Hirsch/ [List email - 12/05/2002] | In section 2.7.1. on MessageAbstractType (line [63]) Would it be useful/clearer to add on the ds:Signature paragraph that this means the signature Reference should have a value corresponding to the MessageAbstractType Id value (ie the instance's id value)? In other words "" is not a valid Reference value. | |
121 | Editorial/Frederick Hirsch/ [List email - 12/05/2002] | [30] s/Helleman/Hellman/
[51] s/serves/each serve/ [77] s/Speciation/Specification/ |
|
124 | Editorial/Shivaram Mysore/ [List email - 12/04/2002] | 1)line 346 and 347 have the same anchor; may be we should put the text also under the same instead of creating 2 different anchors. Also add link to RFC - ftp://ftp.rfc-editor.org/in-notes/rfc2437.txt 2)line 359 - [XML-Enc] Add correct link here 3)line 362 and 363 missing links and text. |
Additional Issues Just added, mostly clarification requests at specified paragraph
# |
Type & Source |
Specification Reference & Issue Description |
Proposed Resolution Details (incl Date)& Volunteer (Specification editor(s) if blank) |
212 | Shivram http://lists.w3.org/Archives/Public/www-xkms/2003Mar/0008.html | [190,318]DISCUSS | |
206 |
Frederick
|
[159][163] ISSUE [159],[163]
Why is SOAP role used for XKMS application? Shouldn't this be the XKMS
service URI for XKMS |
I specified the soap role
because that is the identifier that is the unique identifier of the
service under routing. It is like SMTP and DNS MX records, you want to send to XYZ.com but actually the mx tells you to route to spiffymail.com, the address that the client uses is XYZ.com because the service routing gets handled by the mail service, same here. |
209 |
Frederick
|
103-106 [103] Sentence incomplete, probably
should say "is used to obtain the status of a pending request." |
|
200 | Shivram http://lists.w3.org/Archives/Public/www-xkms/2003Feb/0022.html |
As a reminder: Line 522 needs contents. ISSUE - CREATE |
DONE |
202 | Shivram http://lists.w3.org/Archives/Public/www-xkms/2003Feb/0022.html |
Also add in a section on "Versions,
Namespaces URIs, and Identifiers" as in the dsig and xenc core specs. |
DONE |
203 | Reagle http://lists.w3.org/Archives/Public/www-xkms/2003Feb/0027.html |
[41]XKMS supports two processing modes,
synchronous processing and asynchronous processing. |
DONE |
207 |
Frederick
|
190 presumably using UseKeyWith for policy will imply a different application URI/Identifier than those listed. |
DONE |
208 |
Frederick
|
448 in the compliance
table, is "no security" recommended for operations other |
DONE |
211 | Frederick http://lists.w3.org/Archives/Public/www-xkms/2003Feb/0025.html |
[Section 4]DISCUSS
Not a biggie, but I really would like to discuss it
before such a major change.
|
will do |