W3C home > Mailing lists > Public > www-xkms-ws@w3.org > November 2001

RE: URL-level trust (was: Re: XKMS)

From: Mike Just <Mike.Just@entrust.com>
Date: Fri, 30 Nov 2001 15:04:57 -0500
Message-ID: <9A4F653B0A375841AC75A8D17712B9C980F5C2@sottmxs04.entrust.com>
To: "'Jeremy Epstein'" <jepstein@webmethods.com>, www-xkms-ws@w3c.org
Hi Jeremy,

A comment on your last point.

> So I think it's important that a given XKMS server needs a 
> way of providing
> different grades of service to its clients.  I don't know whether this
> should done by the client saying "please validate this 
> certificate as a
> grade 73B certificate" or whether the XKMS server should 
> recognize a request
> as coming from the business payments server and hence enforce 
> a different
> certificate policy.  If the former, the protocol needs some way of
> expressing a request for a policy ("grade 73B"), but *not* 
> sending a list of
> trusted root certificates.  If the latter, it's a feature of the XKMS
> server, and probably doesn't need to be standardized (i.e., 
> the XKMS server
> could determine the trusted roots to use based on the signature on the
> request).
> 

It seems that there is a convergence toward accepting that the "policy" or
"context" or "trust model" can be specified by reference as part of the
request.  Whether this is as part of the URL and/or part of the X-KISS
request is another question; as part of the URL is probably fine though. 

You raise another interesting point regarding validation based on the origin
of the request and suggest that this could be done based on the signature of
the requestor.  I suspect you cite the use of a signed request as an example
since it is certainly not necessary. As a matter of fact, I might prefer to
see an element that allows the requestor to specify some "name" or
"identifier" as part of the request. So long as this field is returned as
part of the authenticated response, the requestor can ensure that the
correct identifier was used. Thus, authentication of the request is not
required. (As a matter of fact, even if the request were signed, you'd still
need to include the name of the signer in the authenticated response.  If
you didn't an attacker could just resubmit an altered request and sign on
their own.)

Such an identifier could arguably just be included in the URL, e.g.
http://xkms.xmltrustcenter.org/us_gov_bridge_ca_confidential?name=Mike_Just
but it seems more reasonable to add a separate element (in case the name
exceeds the length of URL accepted by some servers).  Although I use a
personal name in this example, this name might be the name of an application
(as Jeremy highlights above or the name of a role).

Mike 
Received on Friday, 30 November 2001 15:05:39 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 13:51:43 EDT