Subject: RE: FW: scvp

From: Peter Sylvester <[email-masked]>
Date: Thu, 6 May 2004 20:03:53 +0200 (MEST)

> 
> If we want to go down the route of providing a shorthand notation for a
> validation policy, using an OID just opens up ambiguity. We are assuming
> both client and server have a common understating of both - which add
> additional management overhead.

A dumb client may have no understanding of a policy, it just wan't
some information concerning the usage of a cert in its particular
context. In an extreme case, just a yes/no answer is good,
and the protocol should allow to have such a minimal exchange.

You are describing a way that a client MUST always provide actual
parameters. This seems to me unnecessary overhead at the client. 

If the actual policy parameters are required to be known by the
client, the server can return then in the response, so that they
can be logged by the client if necessary, or transferred to another
relying party, etc. 

We assume that the application of the policy is under the responsibility
of the server, it seems rather natural to me that in case that
the response could be questioned in the future, the server indicated
what it had done. or, the informations gets transferred only once.

>                              It seems like yesterday we had the
> discussion on whether a certificate policy should also have a hash so
> the RP could tell if the policy had changed. If we truly want a
> shorthand notation to a policy then using a hash over the set of input
> parameters provides an unambiguous statement of what is required.

It is absolutely possible that the policy details at the server
will change without a need for a client to get informed, at least
in an enterprise internal  environment. It is at the server side
where all decisions are made for dumb clients.

If the client has a single application context, then a
request should be possible to contain just the reference to
the cert or the cert, and in an extreme, even the policy could be
derived at the server if the client can be identified and authenticated,
in this case the client configuration is minimal.

Peter