Subject: RE: SCVP & validation policies

From: "Trevor Freeman" <[email-masked]>
Date: Thu, 6 May 2004 12:10:59 -0700

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

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Thursday, May 06, 2004 7:45 AM
To: Trevor Freeman
Cc: [email-masked]
Subject: SCVP & validation policies

Trevor,

I have to agree with Denis, in that it was my impression that the 
client would pass an OID to the server to express the validation 
policy to be used. The servers will, in many cases, be local to an 
enterprise, and thus it is very feasible to use a single OID to 
reference a policy that bundles all the parameters together.  In 
fact, I am not even sure that a public SCVP server is better off with 
an ala carte approach to policy specification, but I might be able to 
be convinced.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 6 May 2004 16:27:58 -0400

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