XKMS Last Call Issue 304 Resolution

{Note this message is BCC'd to Carlisle Adams and Tim Moses in the hope of avoiding spam email address harvesting from the archive.)

Carlisle

Thank you for raising the issues on XKMS captured in Last Call issue #304 [1]. 

The work group discussed these issues and agreed on the following resolutions which will be adopted unless additional concerns are raised. (The original issue text follows the body of the original issue message, marked with [A-E].)

1) Section 2.6: Two Phase Request Protocol. [A]

The work group agreed that item 1 is a reasonable point, but that we should stay with our current approach since it works, even though is different. 

2) need to add a MinorResult of "MustRepresent" to the second table in 3.3.1.1. [B]

Work group agrees, MinorResult error code of RepresentRequired was added to the latest draft in section 3.3.1.1 line 122 - see [2]

3 Section 3.3.2:  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. [C]

Work group agrees, this is fixed with the following text at line 123 in the latest draft [2]:
"If the response is signed this provides a cryptographic linkage between the request and the response."

4. Client key pair registration example [D]

There is no key identifier in a key authentication signature because the key is specified by the key authentication type. A proof of possession can ONLY be authenticated by the subject key. Similarly for the symmetric authentication mode. Leaving out the key identifiers deliberately prevents the possibility of error, checking against the wrong key.

5. [E]
The work group agrees with the proposal to change the text in 6.1.2 to say "as described in Section 8.1; see also Appendix C.1.3".
 
This change has been made to the latest draft at line 248, [3]

Regarding the aside, the key derivation algorithm is carried over from v1.0 of the spec. You raise a good point which may require further WG discussion and possibly a new issue. Apart from this the XKMS WG believes your comments have been addressed and assumes issue 304 is closed unless we hear otherwise.

The XKMS WG would like to thank you for reviewing and commenting on the draft XKMS specification.

Regards, 
Frederick Hirsch on behalf of the XKMS WG 

 
Frederick Hirsch
Nokia Mobile Phones

[1] http://www.w3.org/2001/XKMS/Drafts/xkms-spec-lastcall-issues.html

[2] Section 3.3 latest draft: http://www.w3.org/2001/XKMS/Drafts/XKMS-20030723/#XKMS_2_0_LC3_Section_3_3

[3] Section 6.1 latest draft: http://www.w3.org/2001/XKMS/Drafts/XKMS-20030723/#XKMS_2_0_LC3_Section_6_1

[A]
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. 

[B]
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. 

[C]
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. 

[D]
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? 

[E]
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?]

Received on Tuesday, 5 August 2003 14:43:12 UTC