Subject: RE: SCVP & validation policies

From: "Trevor Freeman" <[email-masked]>
Date: Tue, 11 May 2004 18:05:29 -0700

You also have to understand enough so that the administrative
configuration of the client is generating the right kind of request. The
SCVP client is "only following orders" in many instances and has from a
perspective no idea if it is the right kind of request, only if it is
well formed to the rules it has been given. Both the administrator of
the client and the administrator of the server has to understand in much
grater detail what the given policy is. Once you abstract though the
OID, you are placing a greater burden on the OOB admin to admin process.

Trevor

________________________________

From: James Jing [mailto:[email-masked]] 
Sent: Tuesday, May 11, 2004 5:09 PM
To: Trevor Freeman; [email-masked]
Subject: RE: SCVP & validation policies

Agree that the client needs to have all the data in order to build the
request. However, I think "understand" is too strong a requirement. The
client may not need to "understand" the data, some of which may be
factors affecting the server only. Perhaps I am too pedantic about the
word "understand".

Back to indirection, if "understanding" is not a requirement, then the
client need not to be aware that an OID is an indirection to a set of
policies.

James

________________________________

From: Trevor Freeman [mailto:[email-masked]] 
Sent: Wednesday, 12 May 2004 9:49 AM
To: James Jing; [email-masked]
Subject: RE: SCVP & validation policies

The client has to understand what is required to build a request i.e. 
What data does it need to supply to the server. It does not need to be 
aware of the factors which effect the server. 
Trevor 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]]

On Behalf Of James Jing 
Sent: Tuesday, May 11, 2004 4:01 PM 
To: [email-masked] 
Subject: RE: SCVP & validation policies 

I think policy OIDs should remain abstract, or at least can be abstract.

That is that there is no requirement for the client software to 
understand the parameters. 

I am more thinking of using SCVP to validate a certificate in the 
context of a transaction, where the policy OID in SCVP might be used to 
identify such a context to the server. 

For example, a certificate validation request is carried out with regard

to the acceptability of the holder's creditworthiness in the context of 
a credit-based transaction. In this case, the policy OID could be used 
to indicate the class of assuarances that the CA's CSP provides for, 
resulting in the server selecting a subset of acceptable trust anchors. 

James 

-----Original Message----- 
From: Stephen Kent [mailto:[email-masked]] 
Sent: Friday, 7 May 2004 6:28 AM 
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 

This e-mail, and any attachments hereto, is intended only for use by the
named addressee(s) and may contain legally privileged and/or
confidential information.  If you are not the intended recipient, you
are hereby notified that any dissemination, distribution or copying of
this e-mail, and any attachments hereto, is strictly prohibited.  If you
have received this transmission in error, please notify me immediately
and permanently delete the original and all copies and printouts of this
e-mail.

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 12 May 2004 09:25:28 +0200

Trevor,

> configuration of the client is generating the right kind of request. 
 > > SCVP client is ?only following orders? in many instances and has from a The SCVP client is “only following orders” in many instances and has
 > from a perspective no idea if it is the right kind of request, only if it
 > is well formed to the rules it has been given. Both the administrator of

The client does not have to "understand" what the validation given policy is.

The client only needs to know that, for a given application a given OID for 
the validation policy is needed. He does not need to have a clue of the 
details of the validation policy which may remain fully opaque to him.

This means that any validation specific parameter must *not* be part of the 
standard request.

Denis

> Trevor
> 
>  
> 
> ------------------------------------------------------------------------
> 
> request. However, I think ?understand? is too strong a requirement. The 
> client may not need to ?understand? the data, some of which may be 
> word ?understand?.
> Back to indirection, if ?understanding? is not a requirement, then the 
> ------------------------------------------------------------------------
>