RE: Latest Doc set

Comments on latest doc set:

XKMS Part I: Schema

- 2.3 is there a draft of the SOAP transport section ready of review?
Also, what is the intent of this section as opposed to the SOAP Binding
section in the Protocol Bindings doc?

- 2.8.4 - under <PendingNotification> it states "if the
<PendingNotification> element is present the value Pending MUST be
specified as a <RespondWith> value".  But, the table of <RespondWith>
values in 2.8.6 does not include 'Pending'.  Should it be added?

- There seems to have been move toward more extensive use of attributes
since the last time I reviewed the schema.  What was the motivation for
migrating a number of elements to attributes (i.e., ResultMajor,
ResultMinor)?  This isn't necessarily a bad thing, but I'd like to
understand the thinking behind this.  Can you point me a discussion of
the rationale for these changes.

- There are a lot of "&apos;" entities in the text.  These should be
fixed to display as "'" for readability.

- 3.1.1 - The request example includes a
<RespondWith>Multiple</RespondWith> element (also in the example in
3.2.1).  This value for <RespondWith> isn't defined in 2.8.6.  Should it
be?  Also, QueryKeyBinding element is used, but isn't defined until
4.1.11.  A forward reference would be appropriate.

- 5.1.2, 2nd para.  I think we need a better explaination about how the
authentication code value for private key retrieval are used.  I believe
it should be something like - 

"Bob requests a server generated key pair after receiving the
authentication code 3n9cj-jk4jk-s04jf-20934-jsr09-jwik4 through some
out-of-band mechanism.  The request specifies only Encryption and
Exchange Key uses as the key is to be escrowed for possible later
recovery and the security policy of the issuer does not allow escrow of
signature keys.  

The server generates a public-private keypair in response to the
request, generates appropriate certifications, and returns the result to
the client.  The result includes the private key value encrypted using a
key derived from the authentication code value as described in Appendix
C.1.3.  The client can decrypt the private key by computing the
decryption key from the authentication code value in the same manner as
the service.  

To avoid leaking the private key value to unauthorized entities it is
critical that the service and client protect the authentication code
value from disclosure.  The service should not reuse authentication code
values nor should the key derived from an authentication code be used to
encrypt more than a single private key communication."

- 5.4.1, end of first para  - Change the auth code value  so that all
letters are lower case so its consistent with the text.  Showing upper
and lower case while stating capitalization isn't significant is
confusing.

- 9 - Need to fix up the acknowledgments section.  I suggest this list
authors, other XKMS participants, and other contributors and eliminate
any dups.


Part 2: Protocol Bindings

- 2.7 - This discussion seems to be at odds with the rationale, provided
in the Schema doc, for the 'Represent' two-phase protocol.  Should at
least re-word to indicate services may want additional DoS mitigation
beyond that provided by the defined two-phase protocol..

- 3- is there a draft of the SOAP binding information?

Blair

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] 
Sent: Monday, October 21, 2002 2:20 PM
To: XKMS
Subject: Latest Doc set


All, 

	attached is the latest set of docs.

	The revised issues list is in the zip file 'issues2.html'

	I will try to get arround to matching the issues with the
resolution. 

	In the meantime the main outstanding issues are the description
of the SOAP binding and the TLS ciphersuites

	Brian, am I right in thinking that the latest .NET service pack
will fix my problems with the examples? 

		Phill

Received on Monday, 4 November 2002 12:46:02 UTC