Re: comment

Hi Mike,

Thanks for replying. Replies below.

Mike Just wrote:

>
>
> 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.

It seems that XKMS is wanting to present the same interface to the client regardless of
the underlying PKI. However, there are cases where the client may want to send information
in the request which is specific to a particular PKI. For example, certificate policies exist
in the X.509/PKIX world, but not in PGP or SPKI (as far as I know). If we add a mechanism
to allow the client to specify certain certificate policies, then the underlying PKI is not
really transparent to the client. That is the point I was trying to make with regard to Bullet
2.1.12.

>
> > 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.

Are you referring to Bullet 2.4.2.2 ?
"The specification must describe how a client can specify or determine the context in
which a public key assertion will be validated. Context enables 4-corner model support
for example."


> Some have suggested that policy identifiers might be referenced as part of the URI used in the
> request to the X-KISS server.

By "the URI used in the request", are you referring to the particular service port URI used to
invoke the service? If we want this to be interoperable, we would need to standardize those
semantics.

> 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

A more fundamental issue than certificate policies is how the X-KISS server knows which trust
anchors the client wants the server to use when trying to construct or validate a chain of
certificates.
I don't see this addressed anywhere in the current XKMS spec.

I would feel comfortable if we added the following text at the end of Bullet 2.4.2.2:
"As another example, the context may include the trust anchors and certificate policies the
client wants the server to use for validation."

-Yassir.

Received on Wednesday, 21 November 2001 16:02:21 UTC