RE: comment

Hi Yassir,

Thanks for your comments.  Some replies below.

> -----Original Message-----
> From: Yassir Elley [mailto:yassir.elley@sun.com]
> Sent: Friday, November 16, 2001 4:19 PM
> To: www-xkms-ws@w3.org
> Subject: comment
> 
> Bullet 2.1.12 states that the underlying PKI should be 
> transparent to the
> client. Does this mean that an X-KISS client will be unable 
> to take advantage
> of mechanisms specific to a particular underlying PKI? 
>

This bullet more or less captured an original design intent of XKMS for
applications that wanting less underlying complexity (in case they can be
dealt with at a server).  This doesn't preclude specific mechanisms such as
X.509, especially since <ds:KeyInfo> consists of X.509 related sub-elements.

> For 
> example, if the
> underlying PKI is X.509, the X.509 certificate validation 
> algorithm uses trust anchor
> and certificate policy information as inputs. How does the 
> X-KISS Validate service
> know which trust anchors and certificate policies to use when 
> building a validated chain of X.509
> certificates on behalf of a certain client?
> 

X-KISS currently doesn't support this but I think there does need to be a
capability to support some sort of policy or usage selection by the client.
There are some requirements to this effect in the current requirements
draft, reflecting comments from some position papers at the July workshop,
but nothing specifying that certificate policy can be sent by the client.
Some have suggested that policy identifiers might be referenced as part of
the URI used in the request to the X-KISS server. However, if this were
used, there needs to be a way to include the URI in the response (so that
the client can ensure the correct policy was used and enforced).  

Mike