Re: 2.0 Draft 9

Thanks for the latest version Phil, having the examples updated is very 
useful! Comments on "W3C Editors Copy 20th June 2002"
   http://lists.w3.org/Archives/Public/www-xkms/2002Jun/0030.html

   Abstract
   Executive Summary
   1 Introduction

I think the Executive Summary should be collapsed into the Introduction. 
W3C specs don't have ESs.

1.4 Key Information Service Specification Overview (Non-Normative)

   ¶26 X-KISS allows a client to delegate part or all of the tasks
   required to process XML Signature <ds:KeyInfo> elements to a Trust
   service. A key objective of the protocol design is to minimize the
   complexity of applications using XML Signature. By becoming a client
   of the trust service, 

Please don't use the term "trust service." This is 
undefined. I presume XKMS Service = Validate Service | Trust Service, we 
should use these terms. This should be done in section 1.2 .

                               2 Message Format

   ¶35 At the semantic level the XKMS protocol consists of pairs of
   requests and responses. 

I don't know what "at the semantic level" means. Perhaps should just say, 
"TheXKMS protocol consists of ..."

   ¶36 Each XKMS response message contains a MajorResult code that
   determines whether the response is final or further processing is
   required. The protocol is specified in the CSP formalism [CSP] as
   follows:

I'm unfamiliar with CSP and the reference " [CSP] C. A. R. Hoare" doesn't 
help me.

   ¶40 Conforming XKMS services MAY support the use of encryption to
   ensure message confidentiality and MUST support the use of
   authentication to ensure message integrity as follows:
     * The use of XML Signature to authenticate the message payload MUST
       be supported.
     * The use of TLS [TLS] to support authentication and encryption of
       the entire SOAP transaction SHOULD be supported

   Service <C2> [Required]
          The URI of the Web Service port to which the request is
          addressed

I presume this URI also is associated with the terms of the "trust" service 
policy. Should this be stated? Is there a processing requirement that the 
service check this value corresponds to the policy it's actually operating 
under? (For example, I send a signed Validate Request with a low liability 
URI but include a high liability URI in the request to get more bang for my 
buck.)

   3.3 Using Locate and Validate

I'm glad this section is here to explain the difference. If we agree about 
the Service attribute, perhaps something could be said here on that note.

  4.2.2 Element <KeyInfo>

   ¶163 The following schema defines the <KeyInfo> element of the
   KeyInfoType type imported from the XML Signature Specification:
   <!-- KeyInfo -->
   <element name="KeyInfo" type="ds:KeyInfoType" />
   <!-- /KeyInfo -->

Why is this not ds:KeyInfo? Is its semantic or processing different from 
that defined by ds?

   ¶180 The <KeyUsage> element specifies one or more intended uses of
   the key. If no <KeyUsage> is specified all uses are permitted.

   xkms:Encryption
          The key pair may be used for encryption and decryption

   xkms:Signature
          The key pair may be used for signature and verification

   xkms:Exchange
          The key pair may be used for key exchange

Perhaps more needs to be said about this. For instance, what if I have a 
key that can be used in Encryption and Signature? How would you specify 
this, two KeyUsage elements? If it can be used for both, but the service 
only vouches for Signing, what does it mean if I violate the directive?

   ¶184 The following table lists application URIs for common protocols
   and the corresponding format for the identifier information:

A reference to RFC2648 for urn:ietf would be useful.


                           8 Security Considerations

   ¶307 A generally applicable means of preventing a replay attack is to
   place a token in each message that demonstrates to the recipient that
   the message is 'fresh', for example:
     * A message origination time that the recipient verifies by checking
       that it is sufficiently recent.
     * A nonce, that is a piece of random data that was previously issued
       by the user.
     * A message serial number

I'm a little confused on this note. The RequestID is REQUIRED, so, as 
mentioned earlier, a service that makes sure not to respond to a previously 
requested response within a time interval should be straightforward. We are 
also specifying a 2-phase challange response too, right? Do we know both of 
these will need to be used? Are both mandatory to implement, but optional 
to use?

Another consideration worth noting (perhaps) is that while client 
authentication is important to both reading (locate/validate) and writing 
(registration) to the database, its especially so to regisrations. How do 
you deal with folks populating your service with malicious data. (Nothing 
to say on that in this spec aside from warn about it -- if that.)

Received on Friday, 21 June 2002 15:35:52 UTC