[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: SCVP issue



Steve,

I agree with your proposal for MUST support OIDs, SHOULD/MAY support
parameters.

Mike

-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of Stephen Kent
Sent: Friday, August 13, 2004 8:01 AM
To: ietf-pkix@xxxxxxx
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