Last Call Draft 01

Below are comments on the latest draft XKMS specifications.  Overall,
these are looking very good.  

Phill, thanks for all the hard work in pulling the changes and updates
together.

Regards,
Blair


Comments on XKMS Part 1:Schema

Section 2.10.2 - I would like to see us add an explicit statement that
when using Compound request/response messages an XML Signature may be
placed on the CompoundRequest or CompoundResponse elements as well as
any of the inner request/response elements desired.  We should state
there is no requirement the private key used to sign these separate
elements be the same.  If we support this, then our rules imply the
signature on the Compound request/response element covers any signatures
on the inner elements.  I don't see a problem with this, but we might
want to mention it in the text.

	- Para [89] - We should state that Exclusive canonicalization is
REQUIRED for interop purposes, though other algs may be supported in
line with Section 8.

Section 2.10.11 0 - Para[122] states "... response contains the value of
the signature block..."  This could easily be mis-read as containing the
<ds:Signature> element.  Can we change to "...response contains the
base64 encode value from the <ds:SignatureValue> content within the
<ds:Signature> element..." consistent with the subsequent text.

Section 4.2 - Para [215] states "... accepts as input a <ds:KeyInfo>
element that specifies a public key ..."  This seems to be at odds with
the wording in Section 4.3, Para [220] which states "... may specify a
<ds:KeyInfo> element or one or more <UseKeyWith> elements or both.  They
both derive from the QueryKeyBinding type so shouldn't the description
be the same?

Section 5.1 - Para [235] change 3rd sentence "Should access to the
private be lost..." to "Should access to the private key be lost..."

Section 6.1.5 - Para [294].  Why does this start with "NB:" and why is
it bold?

Section 7.1 - Para [235].  Replace initial text "I.e the first" with ",
i.e., the first"

Other Stuff:

- I validated several of the examples against the schema in the spec
(along with XML Sig and XML Enc).  Things seem to be in good shape once
I fixed the formatting induced line breaks.

- The examples have a number of formatting problems when showing long
base64 values.  These are the result of linefeed & whitespace insertion
interacting with the HTML formatting rules.  We should try to fix these.

	- <RSAKeyValue> and <X509Certificate> element strings show short
indented 2nd lines followed by full width lines

	
<Modulus>4i0BEhQ8Jc4tjwZYbvtMyYfBrIGOMx34K4Cdo2pAzoGnV679FLmGHWnQ
               y2cSj39hf5D1mIaPyD3j
/33TdfglTaaKqp7IPf6ei754fOuI/r1HpX7uqsw+j9LC4Z7GnG3yoY/eBJOZ8TRwMnx+Mkwm
opXP

	- </X509Certificate> end tags misformatted as either 

YgPw4qhJfWoZuY/HWHUzZIRSoggipndVfdvUkmsFSx1rR4FMu0mYBjq79OkYsmwISQlaXejU
g==< 
/X509Certificate>

	or

PTEiEQ16Gxz9piUQoFljhI22hEl8ki0hIJlFGnki+K9dhv/7trMrfKSSHAPIDQZuz01P</X5
09Cer
tificate> 


Comments on XKMS Part II: Protocol Bindings

Section 3 - Para [42] change last sentence to read "Use of SOAP 1.1 is
REQUIRED by implementers to insure near term interoperability and
compatibility with existing tools and supporting infrastructure.   Use
of SOAP 1.2 is RECOMMENDED."   This brings it in line with Part 1,
Section 8.

- more funny line breaks with indented follow-on lines in examples.  see
Service attributes.  Also funny formatting on long base64 values noted
above.

Section 3.2 - Para [59] add following text at end of paragraph "Such
namespace promotion is generally undesireable if the XKMS message
contains a digital signature as it may impact subsequent verification."

Section 3.3 - Para [61] replace the paragraph with the following which
fixes references to Part 1.
"Use of the XKMS SOAP binding does not affect processing of the XML
Signature-based elements defined in Part 1: Signatures over types
derived from MessageAbstractType; KeyBindingAuthentication; and
ProofOfPossession.  These are computed as described in Part 1 Section
2.10.2, Section 6.1.4, and 6.1.6 respectively.  Specifically, the SOAP
defined nodes and namespaces do not contribute to the signature
computation."