W3C
XML Key Management Specification (XKMS) Issues List

XKMS WG Chair(s):
Stephen Farrell < stephen.farrell@baltimore.ie >
Shivaram Mysore < shivaram.mysore@sun.com >
XKMS Editor(s):
Phillip Hallam-Baker < pbaker@verisign.com >
Merlin Hughes < merlin@baltimore.ie >
Issues List Maintainer(s):
Phillip Hallam-Baker < pbaker@verisign.com  >
Mike Just < mike.just@entrust.com >

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.


Outstanding Issues

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
http://lists.w3.org/Archives/Public/www-xkms/2003Feb/0024.html
[159][163] ISSUE

[159],[163] Why is SOAP role used for XKMS application? Shouldn't this be the XKMS service URI for XKMS
and the xkms:Locate/Validate QNames for the XKMS/profile?

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
http://lists.w3.org/Archives/Public/www-xkms/2003Feb/0024.html
103-106

[103] Sentence incomplete, probably should say "is used to obtain the status of a pending request."

[106] schema is missing

 
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
http://lists.w3.org/Archives/Public/www-xkms/2003Feb/0024.html
190

presumably using UseKeyWith for policy will imply a different application URI/Identifier than those listed.

DONE
208
Frederick
http://lists.w3.org/Archives/Public/www-xkms/2003Feb/0024.html
448

in the compliance table, is "no security" recommended for operations other
than locate (e.g. registration, validation) since XKMS itself provides adequate security, and confidentiality is  optional?

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