More Comments on Aug 1 Spec

All,

Consider example [88] from 
(http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-part-1.html)

In this example (3.2.1), Bob has performed cryptographic verification of an
XML Signature and intends to use XKMS "Validate" to obtain trust information
about a certificate chain that was ostensibly contained in the XML Signature
that he received.

Why then, does Bob use "KeyValue" as a <RespondWith> value? The example
assumes he already has the capability to parse the X.509 certificate to
extract the public key. If he has the key already, why does he need the
service to give it back to him? He has already performed cryptographic
signature verification.

Bob doesn't really need any <RespondWith> elements in his request. He just
wants an answer about the end-entity certificate and what he can do with the
key.

Also, it should be made clear in this example the nature of the certificate
chain. Is the chain terminated with a self-signed CA certificate or does the
minimal chain in the example end with an Intermediate CA certificate? If so,
how does the service know which certificate to check if neither cert is
self-signed? And if the chain is terminated with a self-signed certificate,
why can't the client trust this chain implicitly (as long as it trusts the
top of the root) and not bother with the service request at all?

I think some prose about the cert chain will help clear things up.

Regards,

Blake Dournaee
Senior Systems Engineer
RSA Security, Inc.
650-295-7548

"A mind all logic is like a knife all blade, it makes the hand bleed that
uses it."


-----Original Message-----
From: Joseph Reagle [mailto:reagle@w3.org] 
Sent: Friday, August 23, 2002 2:20 PM
To: www-xkms@w3.org
Subject: Comments on Aug 1 Spec



http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-part-1.html

It'd be the nice if the IDs for sections and defined words were human 
grokkable instead of: id="Auto631643354419997500Z442".

   [34] XKMS services MUST support synchronous processing. In synchronous
   processing the service returns the final response to the requestor
   using the same communication channel used to issue the request.

What is a channel? Also, this synchronous and asynchronous... For example, 
HTTP typically doesn't have the concept of a channel, so is the question 
here whether I send back the response with 5 minutes, or 5 hours?

  2.3.3 Element <OpaqueClientData>

   [45] The <OpaqueClientData> contains data specified by the client that
   is opaque to the service. An XKMS service SHOULD return the value of
   an <OpaqueClientData> element specified in a request unmodified in a
   response with status code Success.

I must've missed this bit, what's the motivation for this?

   [49] The <RespondWith> element in the request specifies one or more
   strings included in the request that specify data elements to be
   provided in the <ds:Keyinfo> element of the response. 
   [53] The following schema defines the <RespondWith> element::
   <!-- RespondWith -->
   <element name="RespondWith" type="QName"/>
   <!-- /RespondWith -->

Is it a string, or a QName? I think they should be QNames (or URIs). To that

end, I'm still concerned with the design of the query. We now are not only 
including identifiers of element types from other namespaces, we are adding 
are own qualifiers to the query semantic such as and Multiple, PrivateKey, 
Pending, Represent. At the very least, these should be xkms:Multiple, 
xkms:PrivateKey, etc.


   [90] The Locate and Validate operations are both used to obtain
   information about a public key from a Trust 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 Trust 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 Trust Service as meeting its
   validation criteria.

"Under a specified policy." (Note, I continue to hold a minority opinion (of

one I presume <smile/>) that there's not much of a difference between 
locate and validate. There's an implicit query (validate requests more 
elements) and policy, and I prefer such things to be explicit.

   [101] XKMS specifies three elements that specify key bindings, all of
   which are derived from the KeyBindingAbstractType. These elements are:

   KeyBinding
          Specifies the parameters of a particular instance of a key
          binding

   QueryKeyBinding
          A template used to specify one or more key bindings using query
          by example.

   PrototypeKeyBinding
          A template used to specify the key binding parameters requested
          in a registration request.

I don't understand the distinction between these types...? Perhaps links to 
their motivation/example?

   [117] The NotBefore and NotOnOrAfter attributes are optional. If the
   NotBefore attribute is omitted the assertion is valid on any date up
   to but excluding the date specified in the NotOnOrAfter attribute . If
   the NotOnOrAfter attribute is omitted the assertion is valid from the
   NotBefore attribute with no expiry. If both elements are omitted the
   assertion is valid at any time.

The document begins using "assertion" quite a lot, which is not defined. We 
mean the response, right? 




http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-part-2.html

   [21] In addition an XKMS service that supports server generated keys
   MUST support the use of super-encryption as specified in the XKRSS
   protocol.

Super-encrypted should link to the xenc doc for documentation and I don't 
see any discussion of super-encryption in XKRSS.

   [31] In some circumstances requests or responses or to both may
   require transitive authentication. That is a message sent by A and
   authenticated by B may be subject to forwarding and authentication by
   C. In addition some applications may require further measures to
   ensure that messages meet certain legal standards to prevent
   repudiation.

I thought for simplicity's sake, there was only one relationship, between 
the client and service. If the client trusted the service, then it's up to 
the service to determine who/how it deals with under the specified policy? 
(This is something I've remained confused on.)

4.1 Payload Authentication Binding

   Identifier: URN:blahblahblah:w3.org:xkms:payload-I
          No mechanism is used to authenticate the client

These should be URIs, e.g.,:

  http://www.w3.org/2002/03/xkms#:payload-II

Received on Tuesday, 27 August 2002 16:22:25 UTC