Subject: RE: SCVP & validation policies

From: "Trevor Freeman" <[email-masked]>
Date: Tue, 11 May 2004 09:16:54 -0700

Hi Dennis,
The OID is optional for the client to use. Servers don't have to support
this. It become a matter of mutual agreement between the client and
server what the OID represents. An SCVP server must either comply with
any request or return an error so I don't see the validation policy OID
needs any special treatment beyond want SCVP already defines.
Trevor

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Tuesday, May 11, 2004 6:50 AM
To: Trevor Freeman
Cc: Stephen Kent; [email-masked]
Subject: Re: SCVP & validation policies

Trevor,

> Hi Steve,
> It is management of the clients which is at question here. The client
> has a series of input parameters all of which are opaque. The OID is a
> management indirection to a set of parameters. The ambiguity arises
> because the use of the OID assumes both the manager of the client and
> the manager of the server have an accurate understanding of the OID.
> 
> However give the volume of traffic on this point, I will add the
> capacity to pass an optional OID in the request to the server to
> identify a set of parameters in SCVP15.

It is the other way around:

Given the volume of traffic on this point, the parameters should allow
to 
pass a *mandatory *OID in the request to identify a given validation
policy, 
while some specific validation policies may need an additional set of 
parameters.

Denis

> Trevor
> 
> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]] 
> Sent: Thursday, May 06, 2004 1:28 PM
> To: Trevor Freeman
> Cc: [email-masked]
> Subject: RE: SCVP & validation policies
> 
> At 12:10 PM -0700 5/6/04, Trevor Freeman wrote:
> 
>>Hi Steve,
>>If you want to have a shorthand notation for a validation policy,
given
>>we have a finite set of parameters, the I don't see the value of
>>indirection via an OID. Using a hash of the set of inputs provides a
> 
> way
> 
>>of expressing the same thing without introducing ambiguity of does
both
>>parties have a common understating of that this means. At some point
>>someone has to define the policy in terms of the 3280 input
parameters.
>>That definition is just as applicable and consumable by the client as
a
>>server therefore what did we gain from the shorthand notation? It
would
>>be pretty trivial to define some XML which would allow that set of
>>validation parameters to be imported by any SCVP entity.
>>Trevor
> 
> 
> Trevor,
> 
> It is not indirection via an OID, it is identification via an OID. 
> Clients never have to be aware of the parameters if we use an OID, 
> and simplification of clients is one of the goals of SCVP. So I 
> cannot agree with your comment that clients have to be able to 
> consume these parameters.
> 
> Given that as a basis, it seems that we are debating whether to use 
> OIDs or to create some other form of identifier via hashing 
> parameters. I don't see the latter as attractive, since it requires 
> additional specification of the canonicalization and encoding of the 
> parameters to ensure consistency in hash computation between client 
> and server.
> 
> Steve
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 11 May 2004 12:28:12 -0400

Trevor,

I have to agree with Denis here. This is completely backwards from 
what I recall we defined as the requirements in his RFC a while ago. 
OIDs were sufficient to identify a policy, the parameters for which 
were managed via a separate protocol. It seems a lot easier to 
configure a client with an OID per app, than to configure a set of 
parameters for each app.

Steve

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 11 May 2004 18:35:49 +0200

Trevor,

> this. 

I disagree. The "RFC 3280 compliantbasic validation policy", i.e the one 
which only includes basic path validation, with no extra and no shortcuts, 
as defined by RFC 3280, will have an OID. Since this policy does not 
contains values such as root keys, this validation policy needs additional 
parameters.

Intelligent clients may use this one and specify parameters.

Thin clients will simply refer to an OID which refers globally to a 
validation algorithm and its parameters.

I have talked to customers and their position is to have flexible validation 
policies. As an example, some says: if we want to take purposely the risk of 
not testing ARLs, it is our choice. The validation policy should not mandate 
to test ARLs, but if for some validation policies it is adequate to do so, 
it should be possible to do so.

> It become a matter of mutual agreement between the client and
> server what the OID represents. 

Not necessarilly. Since the OID is not in the arc of the server, it may be 
defined by anyone. If that definition is separately accessible both to the 
client and to the server then it can be supported by the server and the 
client may refer to it. In such a case there is no need for a mutual agreement.

> An SCVP server must either comply with any request or return an error 

True.

 > so I don't see the validation policy OID

I don't see the relationship between the true statement above and the 
conclusion.

As already stated on this list, SCVP stands for "Simple", otherwise we will 
have to drop the "S", and then we would have "CVP". :-|

Denis

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Wed, 12 May 2004 17:20:37 +0800

I would like to support that even the validation policy OID itself is
optional for the client to use. As I stated in my earlier post, if a client
fully trust the validation server, then it might not have to specify a
validation policy OID in its request. In that case, it means that the
client trusts the validation server to adopt the default validation policy
predefinied by the management authority of the application domain
(such as an enterprise). For example, in scenario 1 and scenario 3 I
mentioned in my earlier post, if the client request does not specify any
validation policy OID, then server will adopt the default validation
policy. For you reference, scenario 1 and scenario 3 are as follows:

Scenario 1 (single central-managed vlidation policy)

  DPV server:
      only supports a single central-managed vlidation policy
      the validation policy implies all policy-dependent parameters

  DPV client:
      the validation request may optionally specify the vlidation policy OID
      the validation request needs not specify any policy-dependent
          parameters

Scenario 3 (multiple central-managed vlidation policies with a default
validation policy)

  DPV server:
      supports multiple central-managed vlidation policies with one of them
          is the default
      each validation policy implies its policy-dependent parameters

  DPV client:
      the validation request should specify the vlidation policy OID
      if the request did not specify the vlidation policy OID, then the
         server will use the default one
      the validation request needs not to specify any policy-dependent
         parameters

These are the simplest cases of the use of DPV protocol. I hope that
basic SCVP syntax should support these simplest cases more clearly.
(I mean that the ambiguity in the current syntax should be reduced.)

In contrast to these simplest cases, an extreme case of the use of
DPV protocol is the case where there is no any predefined validation
policy (and hence no default validation policy). This might be the case
where a DPV server is used as a public server. (The scenario 4 I
mentioned earlier.) Please note that in this extreme case, the client has
no way to specify any validation policy OID in its request since there
is no any predefined one.  In this extreme case, the client will have to
submit the full set of parameters for path validation ALGORITHM. I
would like to see SCVP to provide an extension mechanism to
let the client submit the full set of parameters for path validation
ALGORITHM. However, please do not confuse "parameters for
validation ALGORITHM" with "parameters for validation POLICY".
Also, please make a clear separation of basic SCVP syntax and
the extension mechanism for submitting parameters for path
validation ALGORITHM.

Wen-Cheng Wang