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 < Just.Mike@tbs-sct.gc.ca >

Last Updated: December 12, 2002

This page enumerates outstanding and resolved 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)
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 Initial review by Frederick [ List email - 09/25/2002] (resulting in new issues 72-87). This should be reviewed again at final draft.
18	Clarification/ [ Sept 2002 F2F]	[Part I - 2002/08/01] [Part II - 2002/08/01] The specification should have a sanity check performed against the MAY/SHOULD/MUST requirements.	Ensure that this validation is performed prior to moving through Working Group Last Call. [ Sept 2002 F2F] Joseph Reagle Initial review performed by Joseph [ List email - 09/24/2002] (resulting in new issues 89-97). This should be reviewed again at final draft.
36	Editorial/ Shivaram Mysore [ Sept 2002 F2F]	[Part I - 2002/08/01] [Part II - 2002/08/01] Change references to "SOAP" to "SOAP/XMLP".	Make changes as described. [ Sept 2002 F2F] Solved by Phill [ List email - 09/25/2002] Reopened to reflect decision to refer to "SOAP" instead of "SOAP/XMLP" [Nov 14, 2002 - Telecon].
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]
55	Major/ [ Sept 2002 F2F]	[Part II - 2002/08/01] The TBS slots need to be filled in.	Include material or remove TBS note by final draft. [ Sept 2002 F2F]
58	Editorial/ [ Sept 2002 F2F]	[Part I - 2002/08/01] [Part II - 2002/08/01] The acknowledgements sections are blank.	Enter text for both documents (group membership + original authors).[ Sept 2002 F2F]
63	Editorial/ Joseph Reagle [ List email - 08/23/02]	[Part I - 2002/08/01] [Part II - 2002/08/01] It'd be the nice if the IDs for sections and defined words were human grokkable instead of: id="Auto631643354419997500Z442"	This will be done as the document becomes more stable. [ Sept 2002 F2F]
99	Clarification/ [Nov 14, 2002 - TeleCon].	[Part I - 2002/08/01] [Part II - 2002/08/01] Requirement 2.1.3 [ XKMS Requirements] According to this requirement, "Use of optional features is discouraged. Optional features SHOULD be justified in the specification." (Related: Issue 72)	Include justification as appropriate.
102	Editorial/Blair Dillaway [List email 11/04/2002]	[Part I - 2002/08/01] There are a lot of "'" entities in the text. These should be fixed to display as "'" for readability.	Make changes as specified.

Examples Coding 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] Blair will provide Phill with some code [Nov 7, 2002 TeleCon]
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)	Phill Hallam-Baker

Other Issues

#	Type & Source	Specification Reference & Issue Description	Proposed Resolution Details (incl Date)& Volunteer (Specification editor(s) if blank)
115	Major/Merlin Hughes [List email - 12/12/2002]	Proposed modification to former XBULK status requests and responses.
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))
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))
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/
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)
123	Clarification/Ed Simon/ [List email - 12/05/2002]	Proposed changes regarding use of exclusive canonicalization.
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.
25	Major/ Phill Hallam-Baker [ Sept 2002 F2F]	[Part II - 2002/08/01] There is a need for ensuring that the response actually corresponds to the request. This might be achieved by relying on the underlying secure session (e.g. SSL) or including a hash of the request with the response. A piece-wise solution requiring the client to ask for each item of their request to be included in the response seems to be unsatisfactory (since it is difficult to determine the list of sufficient and necessary elements in all cases).	A proposal will be made to the list for including an XML Signature Reference hash (computed over the request) in the request and response. (Though see Issue 26.) [ Sept 2002 F2F] Phill will send example to list [Nov 7, 2002 TeleCon].
30	Major/ Dan Ash [ Sept 2002 F2F]	[Part I - 2002/08/01] In addition to the use of the tail end of the request URI for specifying policy, there is some consensus for explicitly adding a policy URI to the request.	Add a policy URI to the request. It should be extensible using subtyping. [ Sept 2002 F2F] Proposal by Phill [ List email - 09/25/2002]. [Fixed]
57	Clarification/ [ Sept 2002 F2F]	[Part II - 2002/08/01] Should support for PKCS#10 requests be included when X-BULK is rolled into the main specification (see Issue 22).	No. Support for PKCS #10 will be removed. [ Sept 2002 F2F] No change required as this feature was not imported into the base XKMS spec from the former X-BULK specification. Re-opened [Dec 5, 2002 Telecon].
71	Major/ [ Oct 1, 2002 Telecon]	[Part I - 2002/08/01] [Part II - 2002/08/01] There needs to be some clarification as to what it means for a client or service to be "XKMS conformant". Related comment from Phill [List email - 12/04/2002]: "Should we state that all XKMS responders must implement the entire message set even if they do no implement the actual operations? Ie it has to be able to generate a response, but the response might be -not implemented-."	Appropriate text should be added once agreed by the group. For the related comment, there was acceptance; Phill will add some text in a new Conformance section [Dec 5, 2002 Telecon]ec 5, 2002 Telecon]
74	Clarification/ Frederick Hirsch - Requirements Conformance/ [ List email - 09/25/2002]	[Part I - 2002/08/01] [Part II - 2002/08/01] Requirement 2.1.5 [ XKMS Requirements] Wording is needed to clarify that XKMS is transport protocol agnostic - in [32] (Related: Issue 17)	Ensure appropriate wording is added. See also List email - 11/20/2002.
79	Clarification/ Frederick Hirsch - Requirements Conformance/ [ List email - 09/25/2002]	[Part I - 2002/08/01] [Part II - 2002/08/01] Requirement 2.2.8 [ XKMS Requirements] Does the specification need a discussion of establishing a trust relationship with the server to meet this requirement? I think so. (Related: Issue 17)	Stephen will send a proposal to list on using Locate functionality to obtain a Service's key [Nov 7, 2002 TeleCon]. Phill will add proposal from list discussion [Dec 5, 2002 Telecon, List proposal - 12/04/2002]
84	Clarification/ Frederick Hirsch - Requirements Conformance/ [ List email - 09/25/2002]	[Part I - 2002/08/01] [Part II - 2002/08/01] Requirement 2.4.10 [ XKMS Requirements] Specification needs to define how a client can determine the validation context, such as the certificate policy in use. I believe this is bound to the chosen URI for the service - is this clear in the specification? Suggest adding a sentence to [100] stating that the policy is associated with the service URI used by the client. (Related: Issue 17)	Add text as indicated.
96	Editorial/ Joseph Reagle/ Keyword Audit/ [ List email - 09/24/2002]	[Part I - 2002/08/01] [277] Freshness tokens MAY be encoded as XML Signature Properties. More explaination of a "freshness" token would probably be useful. (Related: Issue 18)
103	Clarification/Blair Dillaway [List email 11/04/2002]	[Part I - 2002/08/01] In Section 5.1.2, 2nd para. I think we need a better explaination about how the authentication code value for private key retrieval are used. I believe it should be something like - "Bob requests a server generated key pair after receiving the authentication code 3n9cj-jk4jk-s04jf-20934-jsr09-jwik4 through some out-of-band mechanism. The request specifies only Encryption and Exchange Key uses as the key is to be escrowed for possible later recovery and the security policy of the issuer does not allow escrow of signature keys. The server generates a public-private keypair in response to the request, generates appropriate certifications, and returns the result to the client. The result includes the private key value encrypted using a key derived from the authentication code value as described in Appendix C.1.3. The client can decrypt the private key by computing the decryption key from the authentication code value in the same manner as the service. To avoid leaking the private key value to unauthorized entities it is critical that the service and client protect the authentication code value from disclosure. The service should not reuse authentication code values nor should the key derived from an authentication code be used to encrypt more than a single private key communication."	Make change as specified.
108	Clarification/Frederick Hirsch [List email 11/14/2002]	[Part I - 2002/08/01] 2.8.6 [75] Given the deprecation of MgmtData, should this be removed from the RespondWith Identifier list?	Currently deprecated [List email - 12/04/2002]. Is this enough? No. It will be removed [Dec 5, 2002 Telecon].
114	Major/Merlin Hughes [List email - 11/27/2002]	(Merlin) In XBULK, OpaqueClientData could hold XML content; not just binary data. I don't think that the devolution to base-64 encoded content in XKMS is preferable; I'd rather any namespace="##any" (or ##other). <element name="OpaqueData" type="xkms:OpaqueDataType"/> <complexType name="OpaqueDataType" mixed="true"> <sequence maxOccurs="unbounded"> <any namespace="##any" processContents="lax /> </sequence> </complexType> A different point of view from Frederick [List email - 12/05/2002] Why is the schema for OpaqueClientData an unbounded sequence of OpaqueData elements rather than just a single base64Binary value? Is the idea to allow multiple binary blobs? Does this need justification/explanation?

Proposed Fixes (to be "Resolved" once verified in specification)

Type &
Source

Specification Reference &
Issue Description

Proposed Resolution Details (incl Date)&
Volunteer (Specification editor(s) if blank)

Confirmation of Resolution Needed

#	Type & Source	Specification Reference & Issue Description	Proposed Resolution Details (incl Date)& Volunteer (Specification editor(s) if blank)
21	Clarification/ [ Sept 2002 F2F]	[Part I - 2002/08/01] There is some question as to whether multiple <KeyBinding>s should be allowed to be returned for Register/ReIssue or Revoke/Recovery requests.	It seems reasonable for Register/ReIssue to return multiple <KeyBinding>s in case a use has registered a single public key in more than one CA domain. Similarly, for Revoke/Recovery, a single key revocation may cause the revocation of multiple certificates. Some text needs to be added to clarify this issue. It also appears that the Requirements document should be update to support the return of multiple key bindings. [ Sept 2002 F2F] Phill Hallam-Baker
49	Clarification/ Blake Dournaee [ List email - 08/30/02]	[Part I - 2002/08/01] In Example 5.1.1 when Alice does a registration request I am a bit confused on the nature of the certificate chain that the server sends back. Is it a terminated chain or does it contain an intermediate certificate authority? How does Alice get to choose who the certificate authority is authenticated by? What if she wants to be authenticated by CA Foo instead of CA Bar? Does she get to choose? Should she send a preferred distinguished name of who she wants to be authenticated by? The service might have access to more than one CA.	Add text to indicate that this depends upon the policy contained in the request as well as the policy of the service. The example shown is one possibility: a rooted trust chain.[ Sept 2002 F2F] Mike Just
56	Clarification/ [ Sept 2002 F2F]	[Part II - 2002/08/01] The tables in Section 4 need to be clarified with some headings and additional explanatory text.	Make changes as described. [ Sept 2002 F2F] Partial solution by Phill [ List email - 09/25/2002]
64	Editorial/ Joseph Reagle [ List email - 08/23/02]	[Part I - 2002/08/01] According to para [34], "XKMS services MUST support synchronous processing." In synchronous processing the service returns the final response to the requestor using the same communication channel used to issue the request. What is a channel? Also, this synchronous and asynchronous... For example, HTTP typically doesn't have the concept of a channel, so is the question here whether I send back the response with 5 minutes, or 5 hours?	Add clarifying text. [ Sept 2002 F2F] Proposed partial solution for Issue 4, 5 and 64 from Phill [ List email - 09/26/2002] Proposed partial solution for Issue 5 and 64 from Phill [ List email - 09/26/2002]
70	Clarification [Oct 1, 2002 Telecon]	[Part I - 2002/08/01] Add text describing rules/algorithm that would be used by a client for processing <Status>. (Related: Issue 20)	Add appropriate text. Phill Hallam-Baker
78	Clarification/ Frederick Hirsch - Requirements Conformance/ [ List email - 09/25/2002]	[Part I - 2002/08/01] [Part II - 2002/08/01] Requirement 2.2.6 [ XKMS Requirements] Replay protection is described in general [274], specifically for a nonce [41]. Should the specification give guidance for the other techniques, such as whether Id is intended to serve as a serial #, and regarding use of origination time? Probably not necessary. (Related: Issue 17, Issue 95)	Decided that this was not necessary [Nov 7, 2002 TeleCon]. However, language should be added to clarify Sections 2.6 and 2.7 of Part II, as suggested by Blair [List email - 11/04/2002]. Added by Phill [List email - 12/04/2002]

Resolved Issues

#	Type & Source	Specification Reference & Issue Description	Resolution Details (incl. Date) & Specification Reference (if necessary)
1	Major/ Phill Hallam-Baker, Joseph Reagle [ Sept 2002 F2F]	[Part II - 2002/08/01] Part II should not contain material specific to Web Services Security (WSS).	Remove material specific to WSS from Part II to a separate document that will describe the relationship between XKMS and WSS. [ Sept 2002 F2F] Phill Hallam-Baker, Joseph Reagle Material removed from Part II.
2	Editorial/ Joseph Reagle [ Sept 2002 F2F]	[Part I - 2002/08/01] [Part II - 2002/08/01] Replace instances of the word "assertion" with "key binding" throughout (including such things as "AssertionStatus" to "KeyBindingStatus" as well).	Make changes as described. [ Sept 2002 F2F] Solved by Phill [ List email - 09/25/2002].
3	Editorial/ Joseph Reagle [ Sept 2002 F2F]	[Part I - 2002/08/01] [Part II - 2002/08/01] Refer to "XKMS Services" instead of "Trust Services" throughout.	Make changes as described. [ Sept 2002 F2F] Solved by Phill [ List email - 09/25/2002]
4	Clarification/ Frederick Hirsch [ List email - 09/05/02]	[Part II - 2002/08/01] "I do not understand the distinction between the Pending and Represent responses and flows given in Part 2 of the specification. They look very much the same. It looks like the intent is that one causes an enqueuing for later processing and the other implies a delayed response. My question is, is the distinction necessary, or can we simplify this to be one two-phase request/response? If not, does it make sense to share a common abstract type (e.g. for nonce differences)? If there is a need for both more explanation would be helpful."	Provide clarification as described. [ Sept 2002 F2F] Phill Hallam-Baker Proposed partial solution for Issue 4, 5 and 64 from Phill [ List email - 09/26/2002] Solution accepted by Frederick [Dec 5, 2002 - Telecon]
5	Clarification/ Frederick Hirsch [ List email - 09/05/02]	[Part I - 2002/08/01] "Section 2.1 of Part 1 implies that synchronous responses must be supported and asynchronous is optional [34]. Paragraph [37] gives an example where a service would only support asynchronous by mediating each request with manual administrator review. How would this service be able to also support the syncronous requirement for these messages?"	Provide clarification consistent with paragraph [34]. [ Sept 2002 F2F] Phill Hallam-Baker Proposed partial solution for Issue 4, 5 and 64 from Phill [ List email - 09/26/2002] Proposed partial solution for Issue 5 and 64 from Phill [ List email - 09/26/2002]
6	Major/ Frederick Hirsch [ List email - 09/05/02]	[Part I - 2002/08/01] "Should the spec outline UDDI integration in addition to DNS integration?"	It was decided at the F2F [ Sept 2002 F2F] that no such addition is required.
7	Clarification/ Frederick Hirsch [ List email - 09/05/02]	[ [Part I - 2002/08/01] "My understanding is that GET should not cause side effects in a web architecture. In light of this, should we use POST in 2.3.6 for <PendingNotification> using the HTTP protocol?"	It was decided at the F2F [ Sept 2002 F2F] that no such addition is required.
8	Clarification/ Frederick Hirsch [ List email - 09/05/02]	[Part I - 2002/08/01] "The spec states that if an algorithm does not support a specified key usage then that key usage should be ignored (4.1.3 #106). Perhaps more explanation would be helpful - that since this is used in a request prototype it can safely be ignored because nothing can be returned for this usage anyway."	Provide clarification/example as described. [ Sept 2002 F2F] Phill Hallam-Baker Solved by Phill [ List email - 09/25/2002]
9	Editorial/ Frederick Hirsch [ List email - 09/05/02]	[Part I - 2002/08/01] "4.2.2 [#165] seems to have a typo, should be "The response message" instead of "request"".	Make changes as described. [ Sept 2002 F2F]
10	Clarification/ Frederick Hirsch [ List email - 09/05/02]	[Part I - 2002/08/01] "Is it required of ALL Trust services to revoke a private key when a key recovery is performed? Should this be a requirement? 5.4.1 [#201] Couldn't it be that the recovery is because I formatted my hard drive, but still want to continue to still use the same signing key, for example?" (Related: Issue 51)	The answer to the question is no. Provide clarifying text. [ Sept 2002 F2F] Solved by Phill [ List email - 09/25/2002]
11	Clarification/ Frederick Hirsch [ List email - 09/05/02]	[Part II - 2002/08/01] "I'm not sure why the Payload Binding is not supported (Part 2, [#22]). Does this mean XML Encryption is not allowed for use within XKMS messages?" (Related: Issue 24, Issue 45)	NOT RESOLVED YET. [Fixed - text in question removed]
12	Editorial/ Frederick Hirsch [ List email - 09/05/02]	[Part II - 2002/08/01] "I think it would help clarify the security binding presentation to use grid lines in the tables."	Make changes as described. [ Sept 2002 F2F] Solved by Phill [ List email - 09/25/2002].
13	Clarification/ Phill Hallam-Baker, Joseph Reagle [ Sept 2002 F2F]	[Part I - 2002/08/01] The SRV prefix for an XKMS service in DNS should be specified here once it is established.	Make changes as described. [ Sept 2002 F2F] No further update to the text required. Don Eastlake will submit an Informational RFC in support of this SRV record [ List email - 09/24/2002]
14	Editorial/ Yassir Elley [ Sept 2002 F2F]	[Part I - 2002/08/01] In paragraph [35] of Part I, the term "notification" should be replaced with "pending result".	In paragraph [35] of Part I, replace "XKMS services MUST NOT return notification of an asynchronous response unless requested by the client" with "XKMS services MUST NOT return a pending result for an asynchronous response unless requested by the client.". [ Sept 2002 F2F] Solved by Phill [ List email - 09/25/2002]
15	Editorial/ Brian LaMacchia [ Sept 2002 F2F]	[Part I - 2002/08/01] [Part II - 2002/08/01] IPv6 should be mentioned in addition to IPv4.	Replace all references to IPv4 with either simply IP, or IPv4 and IPv6, as appropriate. [ Sept 2002 F2F]
16	Editorial/ Brian LaMacchia [ Sept 2002 F2F]	[Part I - 2002/08/01] In Section 2.3.1, in the MessageAbstractType, the type for Nonce is ds:CryptoBinary. This is fine if the Nonce is a number, but typically an IV is encoded with Base64.	Ensure that a Nonce is typed as base64. [ Sept 2002 F2F] Solved by Phill [ List email - 09/25/2002]. Proposal accepted at Telecon [Oct 1, 2002].
19	Clarification/ Merlin [ Sept 2002 F2F]	[Part II - 2002/08/01] In a pending request, it is unclear which "original request" the request id is to be taken from.	Provide some clarifying text. [ Sept 2002 F2F] Merlin Hughes
20	Major/ Blake Dournaee [ List email - 08/30/02]	[Part I - 2002/08/01] There is some confusion regarding the structure of the <Status> element and its <StatusValue> child. In particular, there seems to be different status values that should be returned depending on whether a Locate or Validate request is performed. (Related: Issue 69)	Redesign <Status> as described. [ Sept 2002 F2F] Phill Hallam-Baker, Brian LaMacchia Solved by Phill [ List email - 09/25/2002]. Proposal accepted at Telecon [ Oct 1, 2002].
22	Major/ Phill Hallam-Baker [ Sept 2002 F2F]	[Part II - 2002/08/01] Is there a need to have X-BULK as a separate specification.	There was agreement to move X-BULK into the main specification. Merlin will be added as an editor to the main specification. An X-BULK profile of the main specification will still remain, and be maintained by Merlin. [ Sept 2002 F2F] Phill Hallam-Baker, Merlin Hughes Proposal by Phill [ List email - 09/26/2002].
23	Major/ Blair Dillaway [ Sept 2002 F2F]	[Part I - 2002/08/01] [Part II - 2002/08/01] Related to Issue 22, there is a need to support other bulk requests (i.e. for Location, Validation, ...)	Support for multiple requests, for all request types, should be added. A proposed solution for dealing with responses to multiple requests is required (including how to deal with a pending indication for only part of the request). [ Sept 2002 F2F] Phill Hallam-Baker, Brian LaMacchia Proposal by Phill [ List email - 09/25/2002]
24	Clarification/ Phill Hallam-Baker [ Sept 2002 F2F]	[Part I - 2002/08/01] Clients should be warned not to expect that OpaqueClientData provides any confidentiality. The specification should recommend encryption to be used in this case (this would be for payload encryption or encrypting the data before encoding as OpaqueClientData - in other words, outside of XKMS - since the requirements [ XKMS Requirements] recommend against encrypting single elements except private key data). (Related: Issue 11, Issue 45)	Add appropriate clarifying text. [ Sept 2002 F2F] Solved by Phill [ List email - 09/25/2002]
26	Clarification/ Phill Hallam-Baker [ Sept 2002 F2F]	[Part II - 2002/08/01] A clarification is needed from RSA regarding whether their Client Puzzles IPR might cover the reference hash solution proposed in Issue 25.	Clarification from RSA required. [ Sept 2002 F2F] Peter Rostin Clarification sent by Peter [ List email - 09/13/2002]
27	Clarification/ Brian LaMacchia [ Sept 2002 F2F]	[Part I - 2002/08/01] Indicate that for signed server responses, the ResponseID should be randomly generated in order to ensure that the server is not used as an oracle for signing messages that can be pre-determined by a rogue requester.	Provide appropriate text to be added as a security consideration. [ Sept 2002 F2F] Brian LaMacchia Section 8.7 added.
28	Clarification/ Joseph Reagle [ List email - 08/23/02]	[Part I - 2002/08/01] Locate and Validate services are both expected to attempt to provide correct information to the requestor. The Locate and Validate services differ in the extent to which the Trust Service verifies the information returned. A Location service SHOULD attempt to provide only information which is trustworthy to the best of its knowledge. A Validation service undertakes to only return information which has been positively validated by the Trust Service as meeting its validation criteria. "Under a specified policy." (Note, I continue to hold a minority opinion (of one I presume <smile/>) that there's not much of a difference between locate and validate. There's an implicit query (validate requests more elements) and policy, and I prefer such things to be explicit.	Add clarifying text to define/contrast the location and validation operations that is agnostic of particular technologies such as PKIX.[ Sept 2002 F2F] Yassir Elley, Shivaram Mysore, Stephen Farrell Solution proposed by Yassir [ List email - 09/23/2002] Section 3.3 added
29	Clarification/ Joseph Reagle [ Sept 2002 F2F]	[Part I - 2002/08/01] In response to some request, items are returned that have not been asked for by the client (e.g. Validity Period). This is different than most conventional queries (e.g. SQL) where a requester will specify everything that they want returned.	At the F2F [ Sept 2002 F2F], it seemed satisfactory for the server to respond with default items that were not specifically requested but are generally relevant (though see Issue 32).
31	Major/ Brian LaMacchia [ Sept 2002 F2F]	[Part I - 2002/08/01] [Part II - 2002/08/01] As a generalization of the solution for Issue 30, instances of "any" should be removed from the schema, in favour of using subtyping for extensibility.	Remove all instances of "any" in favour of subtyping. [ Sept 2002 F2F] Solved by Phill [ List email - 09/25/2002] Proposal accepted at Telecon [ Oct 1, 2002].
32	Major/ Phill Hallam-Baker [ Sept 2002 F2F]	[Part I - 2002/08/01] "RespondWith" is currently confusing since it asks for elements that relate both to objects and to information about the current session.	Split "RespondWith" into two elements that specify the data elements to be returned, and those elements that are protocol-dependent (e.g. Multiple). Also, extend to include ValidityInterval, KeyUsage and UseKeyWith (which at least partially deals with Issue 29 as well) [ Sept 2002 F2F] Proposal by Phill [ List email - 09/25/2002] [Fixed
33	Major/ Merlin [ Sept 2002 F2F]	[Part I - 2002/08/01] When revoking, are we revoking a key or a KeyBinding? The answer seems to be a KeyBinding.	A proposal will be sent to the list indicating that a KeyBindingID will be specified as part of a revocation (and recovery). The client should be able to <Locate> the bindings they want to revoke. [ Sept 2002 F2F] Merlin Hughes
34	Editorial/ Shivaram Mysore [ Sept 2002 F2F]	[Part I - 2002/08/01] [Part II - 2002/08/01] Rename "QueryKeyBinding" and "PrototypeKeyBinding" to "KeyBindingQuery" and "KeyBinding Prototype" respectively.	Make changes as described. [ Sept 2002 F2F] This change was not made due to the naming conventions adopted by Phill for the entire schema [ List email - 09/25/2002]. This decision was accepted at the Telecon [ Oct 1, 2002].
35	Editorial/ Shivaram Mysore [ Sept 2002 F2F]	[Part I - 2002/08/01] The dates in the Introduction (para [5]) should be updated to cite the most recent F2F and teleconference meetings.	The implementation of this change will be taken care of along with the resolution of Issue 37. [ Sept 2002 F2F]
38	Editorial/ [ Sept 2002 F2F]	[Part I - 2002/08/01] [Part II - 2002/08/01] Remove list of outstanding issues as they are now maintained by this document.	Make changes as described. [ Sept 2002 F2F] Solved by Phill [ List email - 09/25/2002]
40	Editorial/ [ Sept 2002 F2F]	[Part I - 2002/08/01] [Part II - 2002/08/01] Throughout the documents, "'" needs to be replaced with " ' ".	Make changes as described. [ Sept 2002 F2F] Solved by Phill [ List email - 09/25/2002]
41	Editorial/ [ Sept 2002 F2F]	[Part I - 2002/08/01] At para [22], the typeface for <ds:KeyInfo> is incorrect.	Make changes as described. [ Sept 2002 F2F] Solved by Phill [ List email - 09/25/2002]
42	Editorial/ Blake Dournaee [ List email - 08/30/02]	[Part I - 2002/08/01] After para [103], the referred schema for KeyBindingAbstractType is missing.	Add the named schema. [ Sept 2002 F2F] Solved by Phill [ List email - 09/25/2002]
43	Editorial/ Blake Dournaee [ List email - 08/30/02]	[Part I - 2002/08/01] After para [163], KeyInfoQuery is referred to when I believe QueryKeyBinding should be (or KeyBindingQuery when Issue 34 is resolved).	Make changes as described. [ Sept 2002 F2F] Solved by Phill [ List email - 09/25/2002] Solved by Phill [ List email - 09/25/2002]
44	Editorial/ Blake Dournaee [ List email - 08/30/02]	[Part I - 2002/08/01] Para [168] refers to KeyBindingQuery while the schema in [169] refers to QueryKeyBinding.	Based on resolution of Issue 34, the schema in [169] should refer to KeyBindingQuery. [ Sept 2002 F2F] Solved by Phill [ List email - 09/25/2002]
45	Clarification/ Joseph Reagle [ List email - 08/23/02]	[Part II - 2002/08/01] Para [21] refers to "super-encryption". (Related: Issue 11, Issue 24)	XML Encryption should be cited here and the use of so-called "super encryption" should be clarified to indicate that encryption of the private key should always occur, whereas encryption of the payload may also occur. [ Sept 2002 F2F] Solved by Phill [ List email - 09/25/2002]
46	Clarification/ Joseph Reagle [ List email - 08/23/02]	[Part II - 2002/08/01] Regarding the start of Section 4.1: "Identifier: URN:blahblahblah:w3.org:xkms:payload-I" No mechanism is used to authenticate the client. These should be URIs, e.g.,: http://www.w3.org/2002/03/xkms#:payload-II	A naming convention is required. [ Sept 2002 F2F] Proposal by Phill [ List email - 09/25/2002] Question by Joseph [ List email - 10/04/2002] Resolved as suggested by Joseph.
48	Clarification/ [ Sept 2002 F2F]	[Part I - 2002/08/01] The specification should highlight that key recovery is not mandated. (Related: Issue 18)	Make changes as described. [ Sept 2002 F2F] Solved by Phill [ List email - 09/25/2002]
50	Clarification/ Blake Dournaee [ List email - 08/30/02]	[Part I - 2002/08/01] The last sentence of paragraph 186 states: "The request specifies only Encryption and Exchange Key uses as the key is to be escrowed for possible later recovery." Can someone explain to me why (by implication) a key cannot be used for digital signature if it is escrowed for recovery?	Add text to indicate that beyond being a non-repudiation issue, technically, there is no need to recover a signing key (i.e. just get a new one).[ Sept 2002 F2F] Mike Just
51	Clarification/ Blake Dournaee [ List email - 08/30/02]	[Part I - 2002/08/01] Regarding para [201], I don't understand why revoking a key is tied to recovering a key. Can someone explain this to me in more detail? The way it reads now it implies that the service sends back a revoked private key (but it is recovered!). What use does it have if it is now revoked? (Related: Issue 10)	Add clarifying text explaining why it might be done, but indicate that doing this is a matter of policy. For example, [from Phill's notes] "The fact that a recovery process has been performed may require the key to be revoked as policy. This is quite usual in the case of high security keys since the fact that the recovery process is necessary indicates that there has been some security failure. Also the recovery process itself may involve an actual or potential compromise of the key. Add in clarification to state that the key is recovered to allow access to previously encrypted data but the end user is now required to register a new key to receive future encrypted data since the recovery process means that the escrow agents have reconstructed the key." [ Sept 2002 F2F] Mike Just
52	Clarification/ Joseph Reagle [ List email - 08/23/02]	[Part II - 2002/08/01] Regarding Section 2.4, and the topic of "transitive authentication", its purposes seem unclear and there doesn't seem to be a use case.	Rename "transitive authentication" to "persistent authentication" and add clarifying text to indicate that the property is really just an effect of using digital signatures (as opposed to a MAC) for authenticating data. [ Sept 2002 F2F] Solved by Phill [ List email - 09/25/2002].
53	Clarification/ Blake Dournaee [ List email - 08/27/02]	[Part I - 2002/08/01] In example 3.2.1 (para 88), Bob has performed cryptographic verification of an XML Signature and intends to use XKMS "Validate" to obtain trust information about a certificate chain that was ostensibly contained in the XML Signature that he received. Why then, does Bob use "KeyValue" as a <RespondWith> value? The example assumes he already has the capability to parse the X.509 certificate to extract the public key. If he has the key already, why does he need the service to give it back to him? He has already performed cryptographic signature verification.	Change the example to specify KeyName instead of KeyValue. [ Sept 2002 F2F]
54	Major/ [ Sept 2002 F2F]	[Part II - 2002/08/01] More information regarding SOAP binding issues is required. (Related: Issue 73, Issue 90)	Introduce a section in the request/response section that discusses the SOAP binding issues, in particular SOAP faults. [ Sept 2002 F2F] Blair has provided some text for inclusion [List email - 11/14/2002]. Added by Phill [List email - 12/04/2002]
59	Editorial/ [ Sept 2002 F2F]	[Part I - 2002/08/01] [Part II - 2002/08/01] Appendices for "Legal Notices" are no longer required.	Remove the appropriate appendices. [ Sept 2002 F2F] Solved by Phill [ List email - 09/25/2002]
60	Editorial/ Blake Dournaee [ List email - 08/30/02]	[Part I - 2002/08/01] The example following [201] has a random extra XML document inserted. It looks like an unencrypted private key. Is this a typo?	Yes. Fix typo. [ Sept 2002 F2F] Solved by Phill [ List email - 09/25/2002]
61	Major/ Blake Dournaee [ List email - 08/30/02]	[Part I - 2002/08/01] When I first read the description of <KeyUsage> my initial thought was akin to PKIX keyUsageExtension. I suppose I'm wondering if the three options provided (Signature,Encryption,Exchange) are going to be augmented to allow other key usage semantics. Doing this, however, would simply move the complexity from the underlying PKI back to the message syntax. What argument is there to keep the three choices that do exist there while leaving others out (for example, keyCertSign, crlSign)?	Add a separate, optional element for communicating X.509 certificate attributes (OID value).[ Sept 2002 F2F] Proposal by Stephen [ Oct 1, 2002 Telecon] for this requirement to be removed. Stephen to confirm with list. [Fixed]
62	Clarification/ Blake Dournaee [ List email - 08/30/02]	[Part I - 2002/08/01] Referring to para [158], can someone explain why we must MAC twice for a <RevocationCodeIdentifier>? MACing more than once is useful for meeting a certain size constraint, but I don't see a specific size constraint on the <RevocationCodeIdentifier>.	Add clarifying text along the lines of the following: [Phill's notes] "We MAC twice so that the value H(H(x)) is the RevocationCodeIdentifier, H(x) is the RevocationCode. This stops pinheads who chose a well used password as their revocation code from coming to grief. Also beneficial for space reasons and to ensure that character set issues are not problematic." [ Sept 2002 F2F] Solved by Phill [ List email - 09/25/2002]
65	Clarification/ Joseph Reagle [ List email - 08/23/02]	[Part I - 2002/08/01] Regarding paragraph [45], "The <OpaqueClientData> contains data specified by the client that is opaque to the service. An XKMS service SHOULD return the value of an <OpaqueClientData> element specified in a request unmodified in a response with status code Success." I must've missed this bit; what's the motivation for this?	This was discussed and accepted at a previous F2F (see minutes of April 2002 F2F) and agreed that the element may be kept. Some clarifying text will be added. [ Sept 2002 F2F] Solved by Phill [ List email - 09/25/2002]
66	Clarification/ Joseph Reagle [ List email - 08/23/02]	[Part I - 2002/08/01] [49] The <RespondWith> element in the request specifies one or more strings included in the request that specify data elements to be provided in the <ds:Keyinfo> element of the response. [53] The following schema defines the <RespondWith> element:: <!-- RespondWith --> <element name="RespondWith" type="QName"/> <!-- /RespondWith --> Is it a string, or a QName? I think they should be QNames (or URIs). To that end, I'm still concerned with the design of the query. We now are not only including identifiers of element types from other namespaces, we are adding are own qualifiers to the query semantic such as and Multiple, PrivateKey, Pending, Represent. At the very least, these should be xkms:Multiple, xkms:PrivateKey, etc.	Clarify so that QNames are prepended with the qualifying namespace. [ Sept 2002 F2F] Solved by Phill [ List email - 09/25/2002]
67	Clarification/ Joseph Reagle [ List email - 08/23/02]	[Part I - 2002/08/01] Regarding the element definitions at para [101], "a template used to specify the key binding parameters requested in a registration request. I don't understand the distinction between these types...? Perhaps links to their motivation/example?" (Related: Issue 69)	Add clarifying text. [ Sept 2002 F2F]
68	Clarification/ [ Sept 2002 F2F]	[Part I - 2002/08/01] [Part II - 2002/08/01] Separate out the protocol layer of the schema and roll into the protocol document.	It was decided at the F2F [ Sept 2002 F2F] that no such change should be made.
69 (formerly incl in Issue 20)	Major/ [ Sept 2002 F2F]	[Part I - 2002/08/01] It would make more sense for <KeyBinding> to be split along <Locate> and <Validate>. (Related: Issue 20, Issue 67)	Separate <KeyBinding> into <KeyBindingLocate> and <KeyBindingValidate>. It's not clear whether a similar split is required for <QueryKeyBinding>. Redesign <Status>. [ Sept 2002 F2F] Phill Hallam-Baker, Brian LaMacchia Solved by Phill [ List email - 09/25/2002]. Proposal accepted at Telecon [ Oct 1, 2002].
72	Clarification/ Frederick Hirsch - Requirements Conformance/ [ List email - 09/25/2002]	[Part I - 2002/08/01] [Part II - 2002/08/01] Requirement 2.1.3 [ XKMS Requirements] The requirement to justify optional features isn't met explicitly "Use of optional features is discouraged. Use of unbounded XML element schema definitions and optional elements SHOULD be justified in the specification." (Related: Issue 17, Issue 99)	Include justification as appropriate. Requirement to be updated [Nov 14, 2002 - TeleCon]. Requirement updated by Frederick [List email - 11/14/2002] Issue 99 added against spec.
73	Clarification/ Frederick Hirsch - Requirements Conformance/ [ List email - 09/25/2002]	[Part I - 2002/08/01] [Part II - 2002/08/01] Requirement 2.1.4 [ XKMS Requirements] A SOAP binding is required, including a statement that document encoding is used. (TBD in Part 2 now) (Related: Issue 17, Issue 54)	Resolved due to overlap with Issue 54.
75	Clarification/ Frederick Hirsch - Requirements Conformance/ [ List email - 09/25/2002]	[Part I - 2002/08/01] [Part II - 2002/08/01] Requirement 2.1.12 [ XKMS Requirements] Should this requirement for the definition of pkcs#10 and #7 support be removed given Issue 57 resolution - "remove pkcs#10 support"? (Related: Issue 17, Issue 57)	It was decided that this issue could be closed since the requirement is only for a SHOULD [Nov 14, 2002 - TeleCon].
76	Clarification/ Frederick Hirsch - Requirements Conformance/ [ List email - 09/25/2002]	[Part I - 2002/08/01] [Part II - 2002/08/01] Requirement 2.1.13 [ XKMS Requirements] Without a definition of "minimal overhead" this requirement cannot be tested. Do we agree that the specification meets this "guideline"? (Related: Issue 17)	It was decided that we don't need to be too rigorous with defining "minimal overhead." Issue is closed with no changes [Nov 14, 2002 - TeleCon]
77	Clarification/ Frederick Hirsch - Requirements Conformance/ [ List email - 09/25/2002]	[Part I - 2002/08/01] [Part II - 2002/08/01] Requirement 2.2.3 [ XKMS Requirements] TLS profile is required (TBS in part 2). Need to specify acceptable cipher suites. (Related: Issue 17)	Specify cipher suites for TLS support. Stephen will propose some text to list [Nov 7, 2002 Telecon] Stephen's proposal sent to list [List email - 11/14/2002] Added by Phill [List email- 12/04/2002]
80	Clarification/ Frederick Hirsch - Requirements Conformance/ [ List email - 09/25/2002]