RE: Last Call Draft 01

Thanks, I have some comments from Joseph and Roland. I will be editing the
draft on friday before going to RSA so anyone else with comments has till
then to get them in!
 
        Phill

-----Original Message-----
From: Blair Dillaway [mailto:blaird@exchange.microsoft.com]
Sent: Wednesday, April 09, 2003 7:14 PM
To: Hallam-Baker, Phillip; www-xkms@w3.org
Subject: 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+MkwmopXP


        - </X509Certificate> end tags misformatted as either 

YgPw4qhJfWoZuY/HWHUzZIRSoggipndVfdvUkmsFSx1rR4FMu0mYBjq79OkYsmwISQlaXejUg==<

/X509Certificate> 

        or 

PTEiEQ16Gxz9piUQoFljhI22hEl8ki0hIJlFGnki+K9dhv/7trMrfKSSHAPIDQZuz01P</X509Ce
r 
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."