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 >

Last Updated: October 7, 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

Schema Issues

#	Type & Source	Specification Reference & Issue Description	Proposed Resolution Details (incl Date)& Volunteer (Specification editor(s) if blank)
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]
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].
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]
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.

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.
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]
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]
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]
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".	Appropriate text should be added once agreed by the group.

Other Issues

#	Type & Source	Specification Reference & Issue Description	Proposed Resolution Details (incl Date)& Volunteer (Specification editor(s) if blank)
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.
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]
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
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].
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 Hallam-Baker
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
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]
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
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
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
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
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.	Introduce a section in the request/response section that discusses the SOAP binding issues, in particular SOAP faults. [ Sept 2002 F2F] Shivaram Mysore
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]
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
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)	Include justification as appropriate.
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)	Fill-in TBD as indicated.
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.
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)
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)
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
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)
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)
80	Clarification/ Frederick Hirsch - Requirements Conformance/ [List email - 09/25/2002]	[Part I - 2002/08/01] [Part II - 2002/08/01] Requirement 2.2.11 [XKMS Requirements] Need to state in security section of part 1 that server privacy policies may be addressed by server P3P support. (Related: Issue 17)
81	Clarification/ Frederick Hirsch - Requirements Conformance/ [List email - 09/25/2002]	[Part I - 2002/08/01] [Part II - 2002/08/01] Requirement 2.2.12 [XKMS Requirements] Part 1 security section should mention plain-text and data length vulnerabilities and how they might be addressed (or is this more appropriate in a payload confidentiality discussion in part 2?) (Related: Issue 17)
82	Clarification/ Frederick Hirsch - Requirements Conformance/ [List email - 09/25/2002]	[Part I - 2002/08/01] [Part II - 2002/08/01] Requirement 2.4.5 [XKMS Requirements] Bulk registration is being moved into the main specification - Issue 22. (Related: Issue 17, Issue 22)
83	Clarification/ Frederick Hirsch - Requirements Conformance/ [List email - 09/25/2002]	[Part I - 2002/08/01] [Part II - 2002/08/01] Requirement 2.4.6 [XKMS Requirements] Specification of how to request updated status of a multi-key registration should be addressed in the bulk profile when added - Issue 22. (Related: Issue 17, Issue 22)
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.
85	Clarification/ Frederick Hirsch - Requirements Conformance/ [List email - 09/25/2002]	[Part I - 2002/08/01] [Part II - 2002/08/01] Requirement 2.4.16 [XKMS Requirements] The specification MUST define which requests are idempotent (can repeat without ill effect) and which are not. Does the spec make this clear (registration is not, revocation and reissue is not, location and validation are, etc?) (Related: Issue 17)
86	Clarification/ Frederick Hirsch - Requirements Conformance/ [List email - 09/25/2002]	[Part I - 2002/08/01] [Part II - 2002/08/01] Requirement 2.5.4 [XKMS Requirements] X509Chain is required to be defined in the specification. The specification defines it as 1 or more ds:X509Data elements. Should it define the order (from root down or is this unnecessary?) Is a schema definition necessary? Is OCSP well enough defined (appears so) (Related: Issue 17)
87	Clarification/ Frederick Hirsch - Requirements Conformance/ [List email - 09/25/2002]	[Part I - 2002/08/01] [Part II - 2002/08/01] Requirement 2.5.5 [XKMS Requirements] Use of exclusive canonicalization is not specified. Should it be, or is this an application requirement when needed (presume the latter). (Related: Issue 17)
88	Editorial/ Frederick Hirsch - / [List email - 09/25/2002]	[Part I - 2002/08/01] Should "PassPhraseAuthentication" in the text in [214] be "NotBoundAuthentication" to match the schema?	Make change as appropriate.
89	Clarification/ Joseph Reagle/ Keyword Audit/ [List email - 09/24/2002]	[Part I - 2002/08/01] [22] X-KISS allows a client to delegate part or all of the tasks required to process XML Signature <ds:KeyInfo> elements to a Trust service. BTW: It's probably best to replace instances of "XML Signature" with the actual bibliographic token? (Related: Issue 18)
90	Clarification/ Joseph Reagle/ Keyword Audit/ [List email - 09/24/2002]	[Part I - 2002/08/01] [32] XKMS protocol messages share a common format that is carried in the body of a SOAP message. Implementations MAY support other encapsulation formats at their option. SOAP supports multiple serialization/encodings, do we have a MUST associated with one of them? Is this part of this spec, or the binding? http://www.w3.org/TR/SOAP/#_Toc478383512 (Related: Issue 18)
91	Clarification/ Joseph Reagle/ Keyword Audit/ [List email - 09/24/2002]	[Part I - 2002/08/01] [64] The following ResultMajor codes are defined: The "must" in the table should probably be MUST. (Related: Issue 18)
92	Clarification/ Joseph Reagle/ Keyword Audit/ [List email - 09/24/2002]	[Part I - 2002/08/01] [67] In the XML Signature Specification, a signer may optionally include information about his public signing key ("<ds:KeyInfo>") within the signature block. Redundant? (Related: Issue 18)
93	Clarification/ Joseph Reagle/ Keyword Audit/ [List email - 09/24/2002]	[Part I - 2002/08/01] [91] For example a Locate Service MAY act as an aggregator of public key related information obtained from a variety of sources without performing any checks to determine whether specific information is current or establishing any formal trust policy. Such a service would correspond to the role of a directory in a traditional PKI. A Validate service MAY provide a service that validates key information presented to it but does not provide aggregation services. I think I would lowercase these MAYs. (Related: Issue 18)
94	Clarification/ Joseph Reagle/ Keyword Audit/ [List email - 09/24/2002]	[Part I - 2002/08/01] [202] X-KRSS specifies a mechanism for authenticating requests that is independent of any authentication mechanism provided by the message security binding. By its nature the X-KRSS protocol must support requests from parties who have yet to register their credentials or who have impaired credentials which are to be revoked. I think this "must" should be MUST. (Related: Issue 18)
95	Clarification/ Joseph Reagle/ Keyword Audit/ [List email - 09/24/2002]	[Part I - 2002/08/01] [275] The precise mechanism by which replay attacks are prevented is left to the implementation. For example generic mechanism built into the object exchange protocol if specified MAY be used. Is a set of OPTIONAL algorithms for this specified? (Related: Issue 18)
96	Clarification/ 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)
97	Clarification/ Joseph Reagle/ Keyword Audit/ [List email - 09/24/2002]	[Part I - 2002/08/01] [280] Depending on the implementation and application a key recovery operation MAY involve an unacceptable loss of confidence in the security of a private key component. This may lead to the possibility of repudiation of a signed document or of accountability in the case of an encrypted document. The first may should be lower case. (Related: Issue 18)

Fixes Proposed

Block #3

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
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]
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]
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
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]

Block #2

#	Type & Source	Specification Reference & Issue Description	Proposed Resolution Details (incl Date)& Volunteer (Specification editor(s) if blank)
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]
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]

Block #1

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]

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 Issues

#	Type & Source	Specification Reference & Issue Description	Resolution Details (incl. Date) & Specification Reference (if necessary)
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]
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]
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]
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]
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].
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].
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]
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].
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]
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]
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]
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]
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].
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.
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]
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]
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].

References

[Sept 2002 - F2F]
XML Key Management Working Group Face-to-Face (F2F) Meeting Minutes. September 6, 2002.
http://www.w3.org/2001/XKMS/Minutes/20020906-f2f3-draft-minutes.html

[Oct 1 2002 - TeleCon]
XML Key Management Working Group Teleconference Meeting Minutes. October 1, 2002.
http://www.w3.org/2001/XKMS/Minutes/021001-tele.html

[XKMS Requirements]
XML Key Management Requirements draft 1.38, May 23, 2002.
http://www.w3.org/2001/XKMS/Drafts/xkms-req.html

[Part I - 2002/08/01]
XML Key Management Specification (XKMS 2.0) Part II: Protocol Bindings. W3C Editor's Copy 1st August 2002.
http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-part-1.html

[Part II - 2002/08/01]
XML Key Management Specification (XKMS 2.0) Part II: Protocol Bindings. W3C Editor's Copy 1st August 2002.
http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-part-2.html