Comments on XKMS20021017

http://www.w3.org/2001/XKMS/Drafts/XKMS20021017/xkms-part-1.html
W3C Editors Copy 17th October 2002

   [9]This document specifies protocols for distributing and registering
   public keys, suitable for use in conjunction with the proposed
   standard for XML Signatures [XML-SIG] developed by the World Wide Web
   Consortium (W3C) and the Internet Engineering Task Force (IETF) and an
   anticipated companion standard for XML encryption.

jmr: We can probably stop "anticipating" xenc <smile/>.

   [40]An XKMS service MUST NOT return the MajorResult code xkms:Pending
   unless the ResponseMechanism value xkms:Asynchronous was specified in
   the corresponding request.

jmr: This double negative is a little difficult to parse. How about, "An 
XKMS service can only return the MajorResult code xkms:Pending when the 
ResponseMechanism value xkms:Asynchronous was specified in the 
corresponding request." Though we lose our capital key words there... The 
prose and keywords on this part our a little awkward since we are 
essentially describing XKMS's state protocol. Perhaps we should use a table 
to indicate what sort of responses can be sent for a given request?

   [42]XKMS Clients
     * MUST support synchronous processing of X-KISS requests
     * MUST support synchronous processing of X-KRSS requests
     * MUST support synchronous processing of compound XKMS requests
     * MAY support asynchronous processing of X-KISS requests
     * SHOULD support asynchronous processing of X-KRSS requests
     * SHOULD support asynchronous processing of compound XKMS requests

   [43]XKMS services
     * MUST support synchronous processing of X-KISS requests
     * SHOULD support synchronous processing of X-KRSS requests
     * MAY support synchronous processing of compound XKMS requests
     * MAY support asynchronous processing of X-KISS requests
     * SHOULD support asynchronous processing of X-KRSS requests
     * SHOULD support asynchronous processing of compound XKMS requests

jmr: I'm glad we're being explicit on this point, though it demonstrates 
quite a large cross-product of optionality that might be challanging during 
interop...  Also, there's no difference between (X-KISS + X-KRSS) requests 
and (XKMS requests)? Perhaps we should say "support asynchronous processing 
of compound XKMS (X-KISS and X-KRSS) requests".

   [57]If asynchronous processing is performed on the individual inner
   requests each inner request for which an asynchronous response is to
   be accepted specifies the ResponseMechanism value xkms:Asynchronous.
   If the service decides to return an asynchronous response to an inner
   request a compound response is returned with an outer ResultMajor code
   of xkms:Success and and inner ResultMajor code of xkms:Pending for the
   requests for which an asynchronous response is to be issued. A service
   MAY return synchronous and asynchronous responses in a single compound
   response.

jrm: Paragraphs [56-58] are critical to understanding the compound request 
processing and I non-prose (an example, or protocol state) might be helpful 
for comprehension? I've read this a few times and don't feel confident I 
understand it yet.

   [82]The PendingRequest element is used to request the result of a
   previously presented request for which the MajorResult code
   xkms:Pending was returned. The PendingRequest element inherits the
   element and attributes of AbstractRequestType and the following
   attribute:

jmr: The PendingRequest is only sent to the service from the client, after 
the service indicated a change in its state right? Why not just have the 
service send the info? And if not, can the client "bug" the service with a 
PendingRequest after a time-out, or can it only send it after some 
notification? Also, I'm not sure how this relates to the text of 4.3 in 
part II... Are they completely orthogonal, restatements, or complementary.?

   [86] Security Consideration: Care must be taken when signing responses
   to ensure that the service does not provide a signing oracle, that is
   sign a messages whose content is guessable by an attacker.
   Implementations MUST ensure that response messages contain a
   sufficient quantity of unpredictable data such as a pseudo-randomly
   chosen Id attribute. For more information see the section Security
   Considerations.

jmr: We should include a definition or reference for "signing oracle." I 
looked on the Web but didn't find anything very good.

   [107]Request:

jmr: This example needs QName tweeking.


   [119]The Locate and Validate operations are both used to obtain
   information about a public key from an XKMS Service. Locate and
   Validate services are both expected to attempt to provide correct
   information to the requestor. The Locate and Validate services differ
   in the extent to which the XKMS Service verifies the information
   returned. A Location service SHOULD attempt to provide only
   information which is trustworthy to the best of its knowledge. A
   Validation service undertakes to only return information which has
   been positively validated by the XKMS Service as meeting its
   validation criteria.

jmr: Might as well tie this is to the concept of the policy?
s/validation criteria/validation criteria under its optinally specified 
Policy URI/

   [123]In many cases the key information which a client requires is
   bound to some form of address specified by an Internet protocol part
   of which consists of a DNS address. For example an email client may
   require a trustworthy key to send an encrypted email to
   bob@cryptographer.test. Unless an XKMS service which provides key
   information about keys bound to email addresses in the domain
   cryptographer.test is known a priori some means of locating the
   correct XKMS service is required.

jmr: Examples using the *.test and trustcenter domains should be changed to 
example.com . (Unless the IETF/IANA have defined the test top level 
domain?)

   [132]The KeyBindingAbstractType is the abstract type from which all
   XKMS Key Binding element specifiers are derived. It contains the
   following elements and attribute:

   <PolicyIdentifier> [Any Number]
          Identifies the policy under which the Key Binding was issued.
          If multiple Policy Identifiers are specified the Key Binding
          MUST be compliant with all of them.

jrm: I want to confirm that we decided we want multiple 
<PolicyIdentifier>'s? One isn't enough? (And if you have multiple semantics 
in play, you can create a single URI to represent their cross product?)

B.1 Domain Name Service (DNS)

   [330]The provision of an XKMS service that provides information on key
   information bound to DNS addresses in a specified DNS zone MAY be
   advertised by means of the DNS SRV record [RFC 2782]. An SRV record
   contains the following data fields:

jmr: Do we consider a SRV records an optional feature? Without 
implementation/interop, we can't be confident we've gotten the 
specification correctly, particulary given how few registrations there are. 
Also, if folks plan to implement this (and consequently want it to stay in 
the main spec) what processes should we take to register it? Does Don have 
this action item? (I recommend removing this section to a seperate draft if 
the IETF.)

Received on Friday, 22 November 2002 17:55:19 UTC