Subject: RE: SCVP issue

From: "Trevor Freeman" <[email-masked]>
Date: Fri, 13 Aug 2004 11:50:42 -0700

Hi Steve,
I find this posting puzzling. As our private exchange established, the
only mandated field a SCVP client is required to support is the
validation policy reference. Therefore simple clients which only supply
a policy references are conformant to the standard. All other fields are
optional.  True I don't consider a policy reference has to be via an
OID. There are other way to unambiguously refer to a set of rules which
do not burden deployments and are successfully used for the same
function in other standards to there is no precedence that the policy
reference MUST be an OID. SCVP support the use of OIDS but does not
mandate there use since that is ultimately a deployment decision.

One the subject of parameters there is a big difference between optional
standard parameters which are common to all polices e.g. root
certificates, and completely new parameters. A validation policy is not
mandated to cover all standard parameters e.g. it may only define the
root certificates and 3379 mandates that the protocol be capable of
passing other parameters. SCVP defiles how to pass all the standard
parameters associated with the default validation algorithm. Other
non-standard parameters are defined via the validation algorithm OID. 

There are also numerous cases where the corporate wide policy does not
work for all departments or subsidiaries and those departments
/subsidiaries have there own polices. Why cannot a department or
subsidiary have simple devices, have their own policy and simply use the
central server as a resource e.g. the department or subsidiary trusts
the corporate servers to validate requests under a policy that they
define. The state management software for the simple device can handle
multiple parameters. It has to handle at least 3 (server URL, server key
and policy reference) and it is not stressed by a couple more.

Trevor

* -----Original Message-----
* From: [email-masked]
[mailto:[email-masked]]
* On Behalf Of Stephen Kent
* Sent: Friday, August 13, 2004 8:01 AM
* To: [email-masked]
* Subject: SCVP issue
* 
* 
* Folks,
* 
* A few of us have been discussing (off list) the issue of having a
* client send an OID to specify a validation policy at an SCVP (DPV)
* server, vs. having the client send parameters to direct validation.
* 
* My position is that support for OID-based policy references should be
* the default, and the mandatory minimum policy specification mechanism
* for both clients and servers, i.e., a MUST, and that support for
* explicit parameter passing should be an option, a SHOULD or MAY.
* there are several reasons for
* my saying this.
* 
* First, configuring a client to pass an OID is obviously simpler than
* configuring the client with all the parameters needed to direct path
* validation, and with the default policy feature that SCVP must
* support, one could image a zero-config  situation in some contexts.
* In general enterprises find it hard to manage configuration info for
* every client, and this problem is only magnified as the number of
* configuration parameters grows. Thus OID-specified validation is much
* simpler than parameter-specified validation, from a client
* perspective. Since the "S" in SCVP does stand for simple, ...
* 
* Also, as Trevor brought to my attention, one may choose to define
* additional
* parameters that define cert validity for a given application context,
* beyond the standard set of parameters used for path validation. If we
* want a allow an administrator to define such validation policies, we
* can't assume that standard clients will be prepared to convey the
* necessary parameters. This is especially
* true if we assume that the clients and servers are not produced by
* the same vendor. So, only via use of OIDs can we hope to allow such
* customization of cert validity in mixed vendor (or mixed version)
* environments.
* 
* These two points seem to argue for making OIDs the MUST method for
* conveying cert validation selection between  client and server,
* relegating parameter passing to a lesser status, e.g., SHOULD or MAY.
* 
* I'd like to receive feedback fro the list on this issue.
* 
* Steve