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

Addressed Issues -

Schema Issues

#	Type & Source	Specification Reference & Issue Description	Proposed Resolution Details (incl Date)& Volunteer (Specification editor(s) if blank)
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 supports both types. [ Sept 2002 F2F] No, actually make base64...
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 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
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
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]
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]
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]
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]
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]

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
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
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
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
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
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 20)	Add clarifying text. [ Sept 2002 F2F]
69

Fixes Proposed

Block #4 - 26 March 2003

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]

Block #3 Before Feb 2003

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

Block #2

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

Block #1

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

Resolved Issues

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

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

[XKMS Requirements]
XML Key Management Requirements.
http://www.w3.org/TR/xkms2-req

[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