Subject: RE: SCVP issue

From: Stephen Kent <[email-masked]>
Date: Fri, 13 Aug 2004 15:22:08 -0400

At 11:50 AM -0700 8/13/04, Trevor Freeman wrote:
>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.

You start by saying that you don't see why I'm bringing this up on 
this list, but the paragraph above makes it clear that we have very 
different views of what should be mandated support vs. optional 
support.  I've discussed my rationale for why I think OIDs should be 
a MUST, and parameters ought to be a SHOULD or MAY, but our exchanges 
have made no progress. Others in the off list discussion have 
expressed similar concerns. The reason for bringing this to the list 
is simple: if the WG shows a clear preference one way or the other, 
we can make sure the next rev of SCVP represents WG consensus.

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

I don't disagree with your characterization above, but it fails to 
counter the argument I cited for why mandatory support for OIDs 
provides a more general and simpler way to ensure compatibility 
between different client and server implementations.

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

Your argument here assumes a corporate-wide server, which may or may 
not be true. It also assumes an inability for departments to cause 
additional policies to be configured in a corporate server, but an 
ability to correctly manage per-client parameters in all the clients 
for each department that does not follow a monolithic policy. Yes, 
all of these are possible situations, but there are a lot of "ifs" 
here. Also, its not just a matter of the software in the clients 
being able to "handle" the added parameters, but rather the ability 
of folks to correctly manage them.

I notice that you didn't repeat the last argument from our off-list 
discussion, here. There you argued that the decision of which way to 
represent policy (OID vs. list of parameters) was best left to the 
implementers of applications for the clients, vs. local IT managers. 
The argument does not seem to be consistent with the argument above, 
where the issue is one of local IT managers vs. corporate IT 
managers. Since you made the IT manager vs. implementer argument 
before, I though it would be good to mention it here for completeness.

Steve

Steve

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 23 Aug 2004 12:10:59 +0200

To the list (and mainly Trevor),

Back from holidays.

I review the exchanges on the list backwards and I would like to mention the 
first major comment from David Cooper who asks for a clarification between a 
validationAlg and validationPolRef.

On August 4, Trevor tried to explain his point of view on the difference 
between a validation policy and validation algorithm, however I failed to 
understand his explanations that are copied below:

"Validation policy represents is the global set of validation
parameters including the validation algorithm. The validation algorithm
defines how the parameters are compared. If new variables are being
introduced into the validation decision then this cannot be done without
an algorithm to apply the new parameters. I think we agree anything
which effects code such as passing new parameters cannot be a deployment
class variable. I endorse the use of OIDs for implementation class
variable which are hidden from uses and the validation algorithm is an
OID based definition who's intent is to addresses the point you raised.

Given everything is based on path validation, there are, as you say, a
standard set of parameters which are common to all polices which are
therefore defined separately to the validation policy in SCVP so can be
reused in any combination by any validation policy or without a
validation policy if so desired.

Therefore if a validation policy was defining use the corporate trust
anchor with revocation checking using the standard validation algorithm,
I don't think OIDs are mandatory for its definition sine the clients
understand the set of parameters. If you want extra parameters, you need
you clients and servers to implement a new validation algorithm which is
as I said an OID based process."

My point of view is still that validationAlg should simply disappear.

> You start by saying that you don't see why I'm bringing this up on this 
> list, but the paragraph above makes it clear that we have very different 
> views of what should be mandated support vs. optional support.  I've 
> discussed my rationale for why I think OIDs should be a MUST, and 
> parameters ought to be a SHOULD or MAY, but our exchanges have made no 
> progress. Others in the off list discussion have expressed similar 
> concerns. The reason for bringing this to the list is simple: if the WG 
> shows a clear preference one way or the other, we can make sure the next 
> rev of SCVP represents WG consensus.

I support Steve point of view: OIDs are a MUST.

The IESG has refused the use of URLs for long term references (see the 
comments we received from the IESG on the PI draft), so why we should not 
reiterate an attempt to use them (however, the IESG would accept URNs).

I support Steve point of view: validation policy parameters ought to be a 
SHOULD or MAY.

There are two ways to reference a validation policy:

  1) use an OID that has no variable parameters, or
  2) use an OID that has variable parameters.

In the first case, all the parameters related the validation policy are 
below the OID. In the later case, some parameters may be below the OID, 
while some other may be specific to the validation palicy and then MUST be 
specified.

This explains why it is important to distinguish between the two cases, 
proposed on July 28:

ValidationPol ::= CHOICE {
      valPolRef             OBJECT IDENTIFIER,
      valPolDef             ValPolRef }

  ValPolDef ::= SEQUENCE {
      valPolId              OBJECT IDENTIFIER,
      parameters            ANY DEFINED BY valPolId OPTIONAL }

When using valPolRef, all validation algorithms and parameters are fixed.
When using valPolDef, some validation parameters or algorithms may be dynamic.

This is a key issue.

This allows immediately to make a difference between a validation policy 
that has all the parameters self-contained (100 % of the cases for thin 
clients) and a validation policy that has dynamic parameters.

> counter the argument I cited for why mandatory support for OIDs provides 
> a more general and simpler way to ensure compatibility between different 
> client and server implementations.

I disagree with the fact that SCVP should define "how to pass all the 
standard parameters associated with the default validation *algorithm*". 
Parameters related to the *path* validation algorithm defined in section 6 
of RFC 3280 do not need to be part of the basic protocol since they can be 
hidden under a valPolRef (see *my* definition of it).

Then, there can be multiple trust points each one with its own parameters, 
which the current structure with these many optional parameters would not 
allow to support.

However, I do not object to the definition of a specific policy i.e. 
id-scvp1 with whatever parameters are required, provided that it is NOT 
required to implement it.

The parameters from the validation *algorithm* should be part of the 
parameters of the "ANY DEFINED BY valPolId".

This explains why the so-called parameters from the validation *algorithm* 
should NOT be part of the standard parameters from the request (nor from the 
response).

Denis

> Your argument here assumes a corporate-wide server, which may or may not 
> be true. It also assumes an inability for departments to cause 
> ability to correctly manage per-client parameters in all the clients for 
> each department that does not follow a monolithic policy. Yes, all of 
> these are possible situations, but there are a lot of "ifs" here. Also, 
> its not just a matter of the software in the clients being able to 
> "handle" the added parameters, but rather the ability of folks to 
> correctly manage them.
> 
> implementers of applications for the clients, vs. local IT managers. The 
> argument does not seem to be consistent with the argument above, where 
> the issue is one of local IT managers vs. corporate IT managers. Since 
> you made the IT manager vs. implementer argument before, I though it 
> would be good to mention it here for completeness.
> 
> Steve
> 
> Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 23 Aug 2004 11:51:39 -0400

Denis,

I'd glad to hear the lead author of 3379 say that you believe that we 
don't need validation algorithm as a separate part of the validation 
specification.  I had come to believe that too.

Trevor,  I second Denis's suggestion to remove  validationAlg form SCVP.

Russ, as the other author of 3379, do you have an objection?

Steve