Subject: RE: SCVP & validation policies

From: "Trevor Freeman" <[email-masked]>
Date: Mon, 10 May 2004 09:20:23 -0700

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.

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: Denis Pinkas <[email-masked]>
Date: Tue, 11 May 2004 15:50:20 +0200

Trevor,

> 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