Subject: SCVP issue

From: Stephen Kent <[email-masked]>
Date: Fri, 13 Aug 2004 11:01:20 -0400

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

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Fri, 13 Aug 2004 18:12:42 +0200

Stephen Kent wrote:

> validation, [...]

In other words, OID enables server based configuration management, 
whereas the other has to be client based.

Seen like that, this is /etc/host against DNS, and there is no 
hesitation as to which one is the right choice.

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Sat, 14 Aug 2004 01:33:23 +0800

My position is that since SCVP is supposed to be a "simple"
protocol, it sould in default provide better support to simple clients.

I do not object to provide the possibility to allow a "complex"
client to send a full set of parameters to a "complex"
server. However, this can be done via an EXTENSION
mechanism. I strongly suggest that we should remove
all parameter fields from the current syntax and instead add
an EXTENSION mechanism to the SCVP Query
structure or the Validation Policy reference structure.
And then, we can define some standard EXTENSIONs
to allow a "complex" client to send RFC 3280 parameters,
revocation info requirements, or additional conditions (such
as name matching rules, key usage requirements, etc.)
to a  "complex" server that understand these extensions.
This way, we will keep the basic syntax of SCVP as simple
as possible but preserve the extensibility of the protocol.

=====
Wen-Cheng Wang

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 23 Aug 2004 13:24:06 +0200

Trevor,

> as possible but preserve the extensibility of the protocol.

I fully support this position.

Denis

>>Also, as Trevor brought to my attention, one may choose to define
> 
> additional
>

---

From: "Sean P. Turner" <[email-masked]>
Date: Tue, 24 Aug 2004 13:20:37 -0400

I agree with the "simple" protocol argument and I like the OIDs as the 
mandatory over the parameters.  As to whether oid and parameters are in 
the same structure or in a separate extension ... well that's the next 
discussion.

spt

Stephen Kent wrote:

> explicit parameter passing should be an option, a SHOULD or MAY. there 
> are several reasons for
> my saying this.
>
> support, one could image a zero-config  situation in some contexts. In 
> general enterprises find it hard to manage configuration info for 
> 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

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 24 Aug 2004 12:27:37 -0700

Steve,

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

Mike

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

Steve