Comments on XKMS Last Call Draft...

Hi Phill,

I've just been having a quick read through the XKMS spec (since it's in Last
Call!) and I have a couple of comments.  I think these should be cleaned up
before the spec is approved.

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 <Result>.  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 <RequestSignatureValue>.  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 <KeyBindingAuthentication> 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 <UseKeyWith> elements in
<PrototypeKeyBinding>?  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?]

Carlisle.