Subject: RE: FW: scvp

From: "Trevor Freeman" <[email-masked]>
Date: Thu, 6 May 2004 11:33:18 -0700

If a client really trusts the server like in the enterprise, then the
client can take the default for everything. What I am suggesting is that
there could be a long or short had way of expressing the policy and a
client can choose either. Given we have a well know list of parameters,
we can pass them directly or indirectly via a hash. Explicit passing is
more robust since it is unambiguous and requires no configuration on the
part of the server. The client also has a fallback in the event he
server does not recognize the shorthand. I do not buy the argument that
using a shorthand is easer to manage. You MUST at some point define the
policy in terms of the validation input parameters and that definition
can just as easily be consumed by the client as the server. So all I see
is the shorthand saves bandwidth - which is a minimal gain.
Trevor

-----Original Message-----
From: Peter Sylvester [mailto:[email-masked]] 
Sent: Thursday, May 06, 2004 11:04 AM
To: [email-masked]; [email-masked]; Trevor Freeman
Cc: [email-masked]
Subject: RE: FW: scvp

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

---

From: Stephen Kent <[email-masked]>
Date: Thu, 6 May 2004 16:23:24 -0400

At 11:33 AM -0700 5/6/04, Trevor Freeman wrote:
>client can take the default for everything.

That seems unlikely to me, not because of trust issues, but because 
the validation policy may (should?) be application specific and thus 
the client may need to assert a per-application policy to ensure that 
the validation process is appropriate to the application.

>  What I am suggesting is that

The definition of the parameters is done via a separate protocol, and 
is a management activity that the client may never have to employ. 
So, on that regard, I disagree that the client needs to "consume" 
these parameters.

I would rather see a set of parameters referenced via an OID, than 
via a hash of the parameters, to keep things simpler.

Steve

---

From: "Florian Oelmaier" <[email-masked]>
Date: Fri, 7 May 2004 01:33:25 +0200

> If a client really trusts the server like in the enterprise, 
> then the client can take the default for everything.

Thats only partly true - one of the nice things with the policy
reference is that I can choose different validation and trust settings
for different applications. Outlook, Eudora and ohter Mail programs use
the validation setting A, Mozilla, Internet Explorer and Opera the
setting B and my Web-signing application and the ERP software uses C. 

[...]

-- 
Florian Oelmaier
SyTrust