XML Key Management Specification (XKMS) Issues List

1. 1. Section 2.6: Two Phase Request Protocol. As far as I can tell from the text, the purpose of the two phase protocol and the nonce is for the service to protect itself against Denial of Service attacks and against replay attacks. So why is it sensible to make the client trigger this by including "Represent" in the first request message? How does the client know that the service will want to do this?
   On p.15 it says that if the service requires use of the two phase protocol and the requester did not put "Represent" in the request, then the service is to return a MajorResult of "Receiver" and a MinorResult of "MustRepresent". This logic seems odd -- almost as if the service is returning an error for a badly-formed request (even though the requester can't have known beforehand that this was needed). It would be preferable, I think, to simply send the regular response with a MajorResult of "Represent"; if the requester can't deal with this, then *it* should send the error message.
2. Section 3.3.1: Element . Related to the previous comment, I'll just note that if you want to keep the interchange the way it is currently specified then you need to add a MinorResult of "MustRepresent" to the second table in 3.3.1.1.
3. Section 3.3.2: Element . The last line of the first paragraph says, "This provides a cryptographic linkage between the request and the response." Note that it's only a "cryptographic linkage" if the response is signed or cryptographically protected in some other way. The conditions in the remainder of the section do not say this.
4. Section 6.1.1: Example: Registration of Client-Generated Key Pair. In the element, there is no key identifier. How is the service supposed to know which key to use to verify this binding? Is it supposed to be implied from the elements in ? If so (or if there's some other way that the service is supposed to figure this out), shouldn't this be specified somewhere so that implementers know what to build?
5. Section 6.1.2: Example: Registration of Service-Generated Key Pair. The third paragraph talks about encrypting the returned private key using a symmetric key derived from the authentication code and includes the following text: "as described in Appendix C.1.3". But Appendix C.1.3 does not describe this process in any way. What should be said is "as described in Section 8.1; see also Appendix C.1.3". [As an aside, was the key derivation algorithm in Section 8.1 created for the purposes of this specification? Are there not standard ones out there (e.g., in FIPS, ANSI, etc.) that could have been used instead?]

1. Section 1 says there are two "service specifications" but doesn't say where they are more fully described or specified. Forward references?
2. The sections in section 1.7 do not correspond to the sections of the table of contents.
3. Section 1.5 has the same title as Section 4 (except that it has "specification"). How to make this flow better, or at least use the term (r not) "specification" consistently.
4. Generally, I don't distinguish between a "message format" and a "message syntax." What do these section do differently?

1. The choice of inner results in CompoundResult should have a minOccurs attribute of 0, rather than defaulting to 1. The text at paragraph 77 of the XKMS spec part I indicates that there can be zero or more inner responses. This makes sense because a service which does not support compound requests will want to return an empty CompoundResult.
2. The comment field just above the CompoundResult definition mistakenly refers to it as "CompoundResponse".

1. As far as can see, there is no way to specify the desired key type (RSA/DSA/...) in <xkms:LocateRequest/> or <xkms:ValidateRequest/>. This is not a major problem because XKISS server may return a list of keys but I think that in most case the desired key type is known to the client and could be used to narrow key search on the server side (and reduce network traffic :) ). For example, I can easily imagine that RSA and DSA keys would be stored in different database tables. Key type may limit key search to one table instead of two.
2. It does not seem that there is a way to use symmetric keys. While public key cryptography is became more and more afordable, there are still situations when symmetric key cryptography is usefull either because of performance, legacy or some other reasons. An use case example might be a couple of high traffic servers when one stores some sensitive data on the client in an encrypted format (say, in cookies) and another one decrypt this data. These two servers may use XKISS server as a central keys storage (for example, to provide keys rotation). Using symmetric keys might be desirable because of performance reasons as well as small encrypted data size.
3. In the schema for <xkms:ValidityInreval/> element "NotBefore" and "NotAfter" attributes do not have "use=\"optional\"" specified. 3) The "maxOccurs=\"3\"" for <xkms:KeyUsage/> element may prevent schema extension in the future, I would suggest to change this to "maxOccurs=\"unbound\"".
4. Interop Test suite available ??

Fixed

1. In section 2.5.2 it is described:
   ..........
   Service generation of the Pending Response Message RequestID is set to the value of Id in the Pending request message Nonce is not present ResponseID is set to a randomly generated unique value
   ..........
   
2. Corresponding example the values are not given correctly: In 2.5.3.5 Response the value of RequestId should be "#I4294d3993de300c1ef54d49bd0903b2d" according to the specification.
3. Clarify use of "#" before the Id values in XKMS Response

1. Just before line 386, Appendix DReferences -- TYPO; Need Space in between D & References
2. [CSP] TBD -- FILL-IN HERE !!

1. Just before line 75, [PKIX] TDB -- FILL-IN HERE !!
2. [SPKI] TDB -- FILL-IN HERE !!
3. also make items in [] bold to be consistent.
4. line 80 will need a hard reference soon.
5. just before line 84 another item [XML-ns] that needs to be in bold.

Fixed

1. Section 3.1, can we have some other XML elements besides XKMS content inside Body element? Document does not say anything about that.
2. In the SOAP Faults section, error codes are "env:Receiver" and "env:Sender". In any request/response protocol, where you have two messages, Receiver and Sender do not indicate the appropriate system entities. Requester and Responder make more sense. So probably "env:Requester" and "env:Responder" seem little bit better.
3. Section 4, "This specification describes three principal security bindings...". I can see two, Payload Authentication Binding and SSL/TLS Security Binding. Where is the third one?

Fixed - New issue 312 created on subject of open item #11.

Yasir Khan

Clarify use of "#" before the Id values in XKMS Response