Subject: RE: SCVP & validation policies

From: "Trevor Freeman" <[email-masked]>
Date: Wed, 12 May 2004 09:05:56 -0700

Hi Denis,
Any software does not have a clue abut most things in life. To operate
the administrator of the client has to have understand what is going on.
If the administrator does not understand what the implications of their
actions are, then they make mistakes. Your premise is that simplified
administration is only possible in the case of SCVP by the use of the
OID. Given there is a vast quantity of administration software which his
able to present simple choices to the administrator while at the same
time configuring multiple parameters without there knowledge mean this
is not the case.
Trevor

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Wednesday, May 12, 2004 12:25 AM
To: Trevor Freeman
Cc: [email-masked]
Subject: Re: SCVP & validation policies

Trevor,

> You also have to understand enough so that the administrative 
> 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 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.

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
------------------------------------------------------------------------
> 
> 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: "Florian Oelmaier" <[email-masked]>
Date: Wed, 12 May 2004 21:16:18 +0200

> Hi Denis,
> Any software does not have a clue abut most things in life. 
> To operate the administrator of the client has to have 
> understand what is going on. If the administrator does not 
> understand what the implications of their actions are, then 
> they make mistakes. Your premise is that simplified 
> administration is only possible in the case of SCVP by the 
> use of the OID. Given there is a vast quantity of 
> administration software which his able to present simple 
> choices to the administrator while at the same time 
> configuring multiple parameters without there knowledge mean 
> this is not the case. Trevor

There are different roles in the administration. And the "usual
administrator for client software" is a rather different role than the
role of a security administrator. In the meantime (mostly due to the bad
experiences) this is a general accepted model. In most enterprises there
are different people responsible for operating the client and for
managing the security. 

Thus I dont think it is necessary for a client administrator to
understand the implications of settings necessary for certificate
validation. From my perspective there is a move in all areas of security
to strip as many security relevant configuration setting from the client
as possible. And I think it is widespread consensus on this list that
this could be done with SCVP by the use of the OID as a reference to the
validation policy as the sole configuration item.

Florian

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

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 13 May 2004 09:54:01 +0200

Trevor,

(text deleted)

Florian said: "it is widespread consensus on this list that
this could be done with SCVP by the use of the OID as a reference
to the validation policy as the sole configuration item."

I agree.

To respond to a request from Wen-Cheng Wang, the OID of the validation 
policy should be optional in the request. However, if the OID of the 
validation policy is not present in the request, then the OID of the 
validation policy that has been used SHALL be returned by the SCVP server in 
the response. If the validation policy has dynamic parameters, then these 
parameters SHALL be returned too.

Now, we need to move, Trevor.

Would you propose in an e-mail extracts of an ASN.1 syntax that would 
accommodate these requirements for both the request and the response, 
focussing on the validation policy elements ?

Thanks,

Denis

(text deleted)