Subject: RE: SCVP & validation policies

From: Peter Sylvester <[email-masked]>
Date: Mon, 10 May 2004 13:26:44 +0200 (MEST)

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

One often uses the term I am conformant to protocol XYZ or profile ABC
instead of repeating the finite number of the characters in the relevant text.   

>                          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

'understating', I guess you mean 'understanding'. As I said, a dumb client
has no understanding, so there is no ambiguity problem. 

> someone has to define the policy in terms of the 3280 input parameters.
At the server end, at the place where the trust is managed. Dumb
clients don't need to be updated when the details change.

> 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
That is not the question. As far as I remember, we want a possibility
to have a dumb client and centralised policy management.

> be pretty trivial to define some XML which would allow that set of
> validation parameters to be imported by any SCVP entity.
Beware of those who use the word "trivial". By endcoding these
parameters using XER of the ASN.1 syntax, you have a tr..... ooups ...

Anyway, 

I still would like to know whether the isCa is a shorthand notation
for the explicit value of "keyUsage contains certSign", or whether
it is something else.

Do you agree that testing for a particular extendedKeyusage includes
testing for a conformant keyUsage.

I have not heard how you think to have some uniqueness of requester values
in octet strings, and whether there is can be any other way than pure
hexadecimal (or equivalent) presentation of these values, and what
local matter to match these values with the authenticated identities
could be imagined.

---

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

Hi Peter,
The ambiguity is a management level ambiguity. Using an OID provides no
guarantee that both parties have the common understanding of what the
OID represents.

I think we can use the Cert sign bit in key usage so the is CA bit can
be removed from SCVP15

Testing EKU and KU are totally orthogonal. Consider SSL server
certificate validation. A SSL server can have an RSA, DSA or DH public
key.

Given there are plenty of ways a client can generate a "unique" as well
as other behaviors like it can encode a DN in the octet sting if it
likes I don't see a problem. Its down to the client to do what it thinks
fit. The value is simply replayed by the server so it is treated a
binary blob.

Trevor

-----Original Message-----
From: Peter Sylvester [mailto:[email-masked]] 
Sent: Monday, May 10, 2004 4:27 AM
To: [email-masked]; Trevor Freeman
Cc: [email-masked]
Subject: RE: SCVP & validation policies

One often uses the term I am conformant to protocol XYZ or profile ABC
instead of repeating the finite number of the characters in the relevant
text.   

> parties have a common understating of that this means. At some point

'understating', I guess you mean 'understanding'. As I said, a dumb
client
has no understanding, so there is no ambiguity problem. 

Anyway, 

I have not heard how you think to have some uniqueness of requester
values
in octet strings, and whether there is can be any other way than pure
hexadecimal (or equivalent) presentation of these values, and what
local matter to match these values with the authenticated identities
could be imagined.

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 10 May 2004 19:14:51 +0200 (MEST)

> guarantee that both parties have the common understanding of what the

A dumb client may not have any understanding. If you start requiring
anything, where is the boundary to stop, i.e., why don't you require that
all details of the policy must be known by the server. So far, I do not see
any natural limit somewhere in the middle.  

> I think we can use the Cert sign bit in key usage so the is CA bit can
Ok.

Don't we need a number indicating that a CA needs at least a path length N?
In case you are validating a CA that signs a subca that signs an end entity?

> certificate validation. A SSL server can have an RSA, DSA or DH public
I think I can follow the idea, but are KUs orthogonal?

The EKU is in your example "ssl server",the server knows
what kind of key is in the certificate, thus it can validate whether
the key usage is conformant. One can require that the client has to
set the corresponding KU, since the client has to perform some
corresponding operation. I haven't checked whether the potential
KUs are really orthogonal and correspond to the different key types.

For email EKU, there may be an issue to distinguish between
digital signature and/or non-repudiation. A client may just set
digital signature, but if the cert only contains non-rep, it
wouldn't match.

What would be the work of the server, if you don't specify a KU,
but an EKU of sslserver? Would a cert with just CRL signing
be allowed? 

> likes I don't see a problem. Its down to the client to do what it thinks

The problem in your proposal is that you cannot identify at all any way the data
have been encoded, it can only be done by some external rule that you have to
configure among the partners and the implementation need to be prepared
to have all kinds of decoding rules that allow a matching with authenticated
entities.  

I see no advantadge at all to take any new identifier syntax, in fact, 
no syntax at all, we need identifiers that can be matched against 
identities, identities that we have otherwise available as "generalname". 
flexibility of existing and new forms of identifiers is ensured by the 
totally open form of general name, in particular the othername form. 

> fit. The value is simply replayed by the server so it is treated a

The value is not only simply replayed, it is use for loop detecting
at least in the SCVP text.

---

From: "Trevor Freeman" <[email-masked]>
Date: Mon, 10 May 2004 10:46:47 -0700

Hi Peter,
I think saying the client must validate the ku itself is a big jump, so
allowing the client to pass lets them choose how must certificate
processing they perform.

For the requestor, I don't see any other processing than as binary blob
is necessary. Therefore if you have an octet string, the server just
does a binary companies on the data.

Trevor
-----Original Message-----
From: Peter Sylvester [mailto:[email-masked]] 
Sent: Monday, May 10, 2004 10:15 AM
To: [email-masked]; [email-masked]; Trevor Freeman
Cc: [email-masked]
Subject: RE: SCVP & validation policies

A dumb client may not have any understanding. If you start requiring
anything, where is the boundary to stop, i.e., why don't you require
that
all details of the policy must be known by the server. So far, I do not
see
any natural limit somewhere in the middle.  

Ok.

Don't we need a number indicating that a CA needs at least a path length
N?
In case you are validating a CA that signs a subca that signs an end
entity?

> likes I don't see a problem. Its down to the client to do what it
thinks

The problem in your proposal is that you cannot identify at all any way
the data
have been encoded, it can only be done by some external rule that you
have to
configure among the partners and the implementation need to be prepared
to have all kinds of decoding rules that allow a matching with
authenticated
entities.  

identities, identities that we have otherwise available as
"generalname".

---

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

Hi Denis,
I am not excluding he use of OIDs so your customers can do as they want
and pass whatever additional parameters they like per request. My
customer who find the additional layer of administration unnecessary,
can decide not to use them.
Trevor

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

Trevor,

> Hi Dennis,
> The OID is optional for the client to use. Servers don't have to
support
> 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
> needs any special treatment beyond want SCVP already defines.

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: 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
>>
>>From: Stephen Kent [mailto:[email-masked]] 
>>Sent: Thursday, May 06, 2004 1:28 PM
>>To: Trevor Freeman
>>Cc: [email-masked]
>>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
> 
>>>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
> 
>>>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
> 
>>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: "James Jing" <[email-masked]>
Date: Wed, 12 May 2004 09:01:03 +1000

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

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

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: "Trevor Freeman" <[email-masked]>
Date: Tue, 11 May 2004 16:08:17 -0700

Hi Florian,
A server is under no obligation to process the request. 
If you have a badly configured client, then it will be fixed. If the
request is accurate and the server is misconfigured, then it will be
fixed. This is not about the sanctity of either sides policy but simple
client server request/response semantics. I do not expect the server to
second guess what the problem is and return potentially misleading data.
If the request conflicts with the server locally configured policy,
return the error, if not process the request
Trevor

-----Original Message-----
From: Florian Oelmaier [mailto:[email-masked]] 
Sent: Tuesday, May 11, 2004 3:51 PM
To: Trevor Freeman; 'Stephen Kent'
Cc: 'Denis Pinkas'; [email-masked]
Subject: RE: SCVP & validation policies

> Hi Florian,
> The server either carries out the request or returns an 
> error. We cannot have the server picking and choosing items 
> out of the request since it becomes impossible for the client 
> to determining what happened. That is totally consistent with 
> the needs of the enterprise. Trevor

I see it the other way round: The client sends a request and the server
chooses HOW to answer the request. All responsibilities of the
validation process are determined by the policy of the SCVP server.

We cannot have the configuration of a client set by a user in the
enterprise interfering with centrally managed trust settings. If we
allow this, the idea of central managed trust and validation settings is
well and truly dead.

In my eyes it is the clients task to specify its Validation-Policy OID
and perhaps ist "wishlist" - and then to trust the servers response.
From my perspective this was (is?) one of the most charming features of
SCVP.

Best regards,

Florian 

> From: Florian Oelmaier [mailto:[email-masked]] 
> Sent: Tuesday, May 11, 2004 12:13 PM
> To: Trevor Freeman; 'Stephen Kent'
> Cc: 'Denis Pinkas'; [email-masked]
> > I am not excluding that. A SCVP client may choose to
> > implement the more al a carte or a combination of al-a-carte 
> > plus predefined policy. In every validation policy it may 
> > agree m parameters. That leaves n parameters to be specified 
> > per request. Since we don't know which of the m parameters 
> > will be fixed in any given deployment  we must support any 
> > combination so we must support the full rage of parameter 
> > currently defined. In many situations the overhead of 
> > agreeing these pre-caned selection is an administrative 
> > burden such as a departmental server wanting to implement 
> > special needs. Equally in may corporate deployments there is 
> > no choice with many of the values so you can default every to 
> > whoever is good for the server, so again rendering app 
> > specific policy of no value. Trevor
> 
> Hello Trevor,
> 
> I feel that a solution allowing a client to specify values 
> that the server MUST use will not only harm the usability of 
> SCVP in enterprise environments but also make 
> interoperability between different software vendors on the 
> client side with different servers a lot more difficult.
> 
> If we specify a set of parameters that the server MAY use - I 
> am fine. But please dont allow the client to specify any 
> parameters a server MUST use.
> 
> Best regards,
> 
> Florian Oelmaier
> 
> 
> > 
> > 
> > 
> > Sent: Tuesday, May 11, 2004 9:28 AM
> > To: Trevor Freeman
> > Cc: Denis Pinkas; [email-masked]
> > At 9:16 AM -0700 5/11/04, Trevor Freeman wrote:
> > >Hi Dennis,
> > >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
> > 
> > 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: "Trevor Freeman" <[email-masked]>
Date: Tue, 11 May 2004 16:48:36 -0700

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

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

parameters.

Trevor,

Steve

---

From: "James Jing" <[email-masked]>
Date: Wed, 12 May 2004 10:08:47 +1000

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

-----Original Message----- 

On Behalf Of James Jing 

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 

parameters. 

Trevor, 

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: Peter Sylvester <[email-masked]>
Date: Wed, 12 May 2004 14:14:54 +0200 (MEST)

> allowing the client to pass lets them choose how must certificate
Do you think that it is good, or not?
 
I am not sure that is a good and/or whether this corresponds to the
idea of totally centralized validation, i.e. minimal processing
at the client side.

I tend to say that the client should only be required to
use the public key.

> does a binary companies on the data.

This is not conformant with the requirements, the server needs some
way to match the identifiers with the authenticated identities. To me, an
an almost opaque octet string doesn't seem the right approach.
In fact, you don't have a binary blob, since you don't allow zeros,
for example, if a client want to put a hash of something.

I propose the following compromise:

  Identifiers ::= SEQUENCE OF { 
          CHOICE {
               opaqueId OCTET STRING,
               nameId GeneralName
          }

and a statement says that in order to compare for loop detection, a server
will do a comparision of the encoded element (including the tag).

and use this as the type for requestor and responder

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 12 May 2004 20:09:33 +0200 (MEST)

Denis, 

I assume you mean 'minimal' instead of 'standard',
'the standard rerequest for a very dumb client'
 
> This means that any validation specific parameter must *not* be part of
> the standard request.
> 
> Denis

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 12 May 2004 20:22:39 +0200 (MEST)

trevor,

Your clients may need to be updated each time you change anything
in the structure of your certs, or in the rules of the policies,

Any code that can be avoided, seems good to me in line with
the requirement for dumb client support.   

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

---

From: "Trevor Freeman" <[email-masked]>
Date: Wed, 12 May 2004 11:28:18 -0700

Hi Wen-Cheng,
In scenario 1, the use of and validation policy OID option in a request
is superfluous. The SCVP client simply submits the request and the
server uses its default policy.
In scenario 3 there are two way to achieve this with SCVP. The client
and can be configured with a set of OIDs to represent the policy, or
they can by configured wit the set of parameters to submit. In both
cases the SCVP server certifies the request matches its local policy
before processing the request.
Trevor

-----Original Message-----
From: Wen-Cheng Wang [mailto:[email-masked]] 
Sent: Wednesday, May 12, 2004 2:21 AM
To: Denis Pinkas; Trevor Freeman
Cc: Stephen Kent; [email-masked]
Subject: Re: SCVP & validation policies

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

support
shortcuts,
additional
validation
> policies. As an example, some says: if we want to take purposely the
risk
of
mandate
so,
> Not necessarilly. Since the OID is not in the arc of the server, it
may be
the
agreement.
will

---

From: "Trevor Freeman" <[email-masked]>
Date: Wed, 12 May 2004 12:00:39 -0700

Hi Peter,
The problem of having to push policy to clients of all descriptions is a
well understood problem set. The infrastructure to do that is the main
overhead. The number of parameters associated with that process is not a
significant overhead.
Trevor

-----Original Message-----
From: Peter Sylvester [mailto:[email-masked]] 
Sent: Wednesday, May 12, 2004 11:23 AM
To: [email-masked]; Trevor Freeman
Cc: [email-masked]
Subject: RE: SCVP & validation policies

trevor,

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 14 May 2004 11:59:45 +0200 (MEST)

> 
> Hi Denis,
> As I said previous an OID is one of the possible options, but there is
> no consensus to make this mandatory so SCVP will continue to support
> both options. I also don't see consensus that it is mandatory that a
> SCVP server will always map a request back to the OID.

I can live with this.

> I will be posting SCVP 15 shortly so you can review the latest draft.

Given the previous discussion, I'd like to see a possibility
that the request can be as simple as just sending in the certificate.

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 14 May 2004 12:26:19 +0200 (MEST)

> overhead. The number of parameters associated with that process is not a

You don't push parameters that are subject to change, you need to handle
updates, if you configure one id, the problem of updates is gone.

Whenever you can remove one parameter, you significantly reduce 
the potential problem space (about divide it at least by 2)

But since you have responsed positively to Denis, I may
not even understand what you are saying.

Since three drafts, the whole text is unimplementable,
i.e. almost a year, ...), so the following list of some
(to me) open questions is not necessariy complete.  

- in what way a relay scvp can include an answer from another scvp
  server? please allow to have a place for this. Just provide for
  example a 'content-info' as a placeholder for time stamps, scvp
  responses.

- Is the Nonce field the response to the following req: 

   The DPV server MUST be able, upon request, copy a text field provided
   by the client into the DPV response.  As an example, this field may
   relate to the nature or reason for the DPV query.

- I'd like to know what others think about my compromise proposal
  for requestor/responder.

- I have some feeling that there are at least some different interpretation
  of policies and object identifiers validation algoritithms, etc.

  - OIDs used for a configuration
  - oids to reference some globally recognised rules
  - oids to define sysntaxes of validation algorihms. 

- It is not clear to me whether for example the name matching algorithm
  is at the right level of abstraction. I'd rather have an
  algorithm that say: 'Can this cert be used for this keypurpose,
  for the following names.' It maybe not useful to
  burden the client with the details of adding keyusage and 
  compatible extendedkeyusage.

---

From: "Trevor Freeman" <[email-masked]>
Date: Fri, 14 May 2004 09:35:30 -0700

See below

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Friday, May 14, 2004 3:26 AM
* To: [email-masked]; Trevor Freeman
* Cc: [email-masked]
* Subject: RE: SCVP & validation policies
* 
* > Hi Peter,
* > The problem of having to push policy to clients of all descriptions
is a
* > well understood problem set. The infrastructure to do that is the
main
* > overhead. The number of parameters associated with that process is
not a
* > significant overhead.
* 
* You don't push parameters that are subject to change, you need to
handle
* updates, if you configure one id, the problem of updates is gone.
* 
* Whenever you can remove one parameter, you significantly reduce
* the potential problem space (about divide it at least by 2)

  [TF] One administrator can defile a policy and that policy can consist
of n parameters living in some kind of object (XML in a file store,
attributes in a directory etc). Other administrators do not need to be
intimately aware of the content of that object to use object, they just
need a pointer which they can use. Therefore the number of parameters in
the object is irrelevant. There is generally a perception that any
policy change has to be applied in a reasonable timeframe therefore any
policy management system has regularly check for updates therefore
frequency of updates tends not to be a issue either. However I really
don't expect SCVP policy of any type to have significant churn.   

* 
* But since you have responsed positively to Denis, I may
* not even understand what you are saying.
* 
* Since three drafts, the whole text is unimplementable,
* i.e. almost a year, ...), so the following list of some
* (to me) open questions is not necessariy complete.
* 
* - in what way a relay scvp can include an answer from another scvp
*   server? please allow to have a place for this. Just provide for
*   example a 'content-info' as a placeholder for time stamps, scvp
*   responses.
[TF] Up to now one of our objective was to hide any complexity that may
arise out of relay. There is also no guaranteed correlation between
relayed requests. A client may make a DPV request and the server may
intern make a DPD request to another SCVP server so embedding the DPD
response to he DPV request is on no value.
* 
* - Is the Nonce field the response to the following req:
* 
*    The DPV server MUST be able, upon request, copy a text field
provided
*    by the client into the DPV response.  As an example, this field may
*    relate to the nature or reason for the DPV query.
* 
* - I'd like to know what others think about my compromise proposal
*   for requestor/responder.
* 
* - I have some feeling that there are at least some different
* interpretation
*   of policies and object identifiers validation algoritithms, etc.
* 
*   - OIDs used for a configuration
*   - oids to reference some globally recognised rules
*   - oids to define sysntaxes of validation algorihms.
[TF] Yes I have been thinking that an OID alone is to restrictive.
Others may want to use a URL to point to a policy so we need a couple of
built in choices plus an extension mechanism for other to define other
reference types.
* 
* - It is not clear to me whether for example the name matching
algorithm
*   is at the right level of abstraction. I'd rather have an
*   algorithm that say: 'Can this cert be used for this keypurpose,
*   for the following names.' It maybe not useful to
*   burden the client with the details of adding keyusage and
*   compatible extendedkeyusage.
[TF] I was specially asked to do the name matching example because it is
widely used today. I am sure others can submit other policy example as
separate IDs.
* 
*

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 14 May 2004 19:24:41 +0200 (MEST)

> don't expect SCVP policy of any type to have significant churn.   

Policy changes are not to be applied by any workflow application administrator,
i.e. client administrator. They are made by the security administrator.

> * not even understand what you are saying.

Well, since you have already agreed that it is posssible just to use a policy oid
there is no need to discuss further whether the alternative is good,
useful, practical or whatever. 

> response to he DPV request is on no value.

inverse logic A ==> B is not the same as  not A ==> not B
the fact that you may find one case where is doesn't make sense
to include a response, doesn't mean that it never makes sense.
And in the given example, in particular when there is no
correlation, who can the realy prove that it has provided
his a particular response based on whatever other response?  

'our objective'? RFC 3379 says: 

   The DPV request MUST allow the client to request that the server
   include in its response additional information which will allow
   relying parties not trusting the DPV server to be confident that the
   certificate validation has correctly been performed.  Such
   information may (not necessarily exclusively) consist of a
   certification path, revocation status information from authorized CRL
   issuers or authorized OCSP responders, revocation status information
   from CRL issuers or OCSP responders trusted under the validation
   policy, time-stamp tokens from TSAs responders trusted under the
   validation policy, or a DPV response from a DPV server that is
                      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

   trusted under the validation policy.  When the certificate is valid
   according to the validation policy, the server MUST, upon request,
   include that information in the response.  However, the server MAY
   omit that information when the certificate is invalid or when it
   cannot determine the validity.

> *    relate to the nature or reason for the DPV query.

???? no answer?

> *   for requestor/responder.
???? no answer?

> [TF] Yes I have been thinking that an OID alone is to restrictive.

You already have for example a validation algorithm OID for
name validation (like the qulifiers in Policyinfo)
plus the required necessary parameters together with
the configuration policy OID.  

> built in choices plus an extension mechanism for other to define other

More than the qualifier logic in the PolicyInfo? 

> widely used today. I am sure others can submit other policy example as

I agree fully that the there is some good purpose of this kind of algorithm. 
I am just wondering whether the EXAMPLE specification is sufficiently
well defined. Looks like may ask for three quarks with
keyusage, extendedkeyusage and validation algorithm instead
of asking for some more obvious atomic things.

If I am an ssl client or server, I simply don't care whether the
actual certificate has whatever key usages or so, I just want a yes/no
answer and maybe a path for logging. I just give the set of
names and certs, 

Do we need to distinguish email-protection certs for signing and encryption?

---

From: "Trevor Freeman" <[email-masked]>
Date: Fri, 14 May 2004 12:27:40 -0700

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Friday, May 14, 2004 10:25 AM
* To: [email-masked]; Trevor Freeman
* Cc: [email-masked]
* Subject: RE: SCVP & validation policies
* 
* 
* >
* >   [TF] One administrator can defile a policy and that policy can
consist
* > of n parameters living in some kind of object (XML in a file store,
* > attributes in a directory etc). Other administrators do not need to
be
* > intimately aware of the content of that object to use object, they
just
* > need a pointer which they can use. Therefore the number of
parameters in
* > the object is irrelevant. There is generally a perception that any
* > policy change has to be applied in a reasonable timeframe therefore
any
* > policy management system has regularly check for updates therefore
* > frequency of updates tends not to be a issue either. However I
really
* > don't expect SCVP policy of any type to have significant churn.
* 
* Policy changes are not to be applied by any workflow application
* administrator,
* i.e. client administrator. They are made by the security
administrator.
[TF] Nice ideal, but Administrators of all descriptions make security
related decisions.

* 
* > * But since you have responsed positively to Denis, I may
* > * not even understand what you are saying.
* 
* Well, since you have already agreed that it is posssible just to use a
* policy oid
* there is no need to discuss further whether the alternative is good,
* useful, practical or whatever.
* 
* > *
* > * Since three drafts, the whole text is unimplementable,
* > * i.e. almost a year, ...), so the following list of some
* > * (to me) open questions is not necessariy complete.
* > *
* > * - in what way a relay scvp can include an answer from another scvp
* > *   server? please allow to have a place for this. Just provide for
* > *   example a 'content-info' as a placeholder for time stamps, scvp
* > *   responses.
* 
* > [TF] Up to now one of our objective was to hide any complexity that
may
* > arise out of relay. There is also no guaranteed correlation between
* > relayed requests. A client may make a DPV request and the server may
* > intern make a DPD request to another SCVP server so embedding the
DPD
* > response to he DPV request is on no value.
* 
* inverse logic A ==> B is not the same as  not A ==> not B
* the fact that you may find one case where is doesn't make sense
* to include a response, doesn't mean that it never makes sense.
* And in the given example, in particular when there is no
* correlation, who can the realy prove that it has provided
* his a particular response based on whatever other response?
[TF] Having the client be unaware that relay happened still seems a
desirable simplification. All it takes is the server to process the rely
reply. I am OK with including an SVVP response from another server for
third party accountability, but not if the client is expected to process
the embedded SCVP response.

* 
* 
* 'our objective'? RFC 3379 says:
* 
*    The DPV request MUST allow the client to request that the server
*    include in its response additional information which will allow
*    relying parties not trusting the DPV server to be confident that
the
*    certificate validation has correctly been performed.  Such
*    information may (not necessarily exclusively) consist of a
*    certification path, revocation status information from authorized
CRL
*    issuers or authorized OCSP responders, revocation status
information
*    from CRL issuers or OCSP responders trusted under the validation
*    policy, time-stamp tokens from TSAs responders trusted under the
*    validation policy, or a DPV response from a DPV server that is
*                       XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
* 
*    trusted under the validation policy.  When the certificate is valid
*    according to the validation policy, the server MUST, upon request,
*    include that information in the response.  However, the server MAY
*    omit that information when the certificate is invalid or when it
*    cannot determine the validity.
* 
* > *
* > * - Is the Nonce field the response to the following req:
* > *
* > *    The DPV server MUST be able, upon request, copy a text field
* > provided
* > *    by the client into the DPV response.  As an example, this field
may
* > *    relate to the nature or reason for the DPV query.
* 
* ???? no answer?
[TF] The nonce is there to bind the request to the response.
* 
* > *
* > * - I'd like to know what others think about my compromise proposal
* > *   for requestor/responder.
* > *
* ???? no answer?
* 
* > * - I have some feeling that there are at least some different
* > * interpretation
* > *   of policies and object identifiers validation algoritithms, etc.
* > *
* > *   - OIDs used for a configuration
* > *   - oids to reference some globally recognised rules
* > *   - oids to define sysntaxes of validation algorihms.
* > [TF] Yes I have been thinking that an OID alone is to restrictive.
* 
* You already have for example a validation algorithm OID for
* name validation (like the qulifiers in Policyinfo)
* plus the required necessary parameters together with
* the configuration policy OID.
* 
* > Others may want to use a URL to point to a policy so we need a
couple of
* > built in choices plus an extension mechanism for other to define
other
* > reference types.
* 
* More than the qualifier logic in the PolicyInfo?
* 
* > *
* > * - It is not clear to me whether for example the name matching
* > algorithm
* > *   is at the right level of abstraction. I'd rather have an
* > *   algorithm that say: 'Can this cert be used for this keypurpose,
* > *   for the following names.' It maybe not useful to
* > *   burden the client with the details of adding keyusage and
* > *   compatible extendedkeyusage.
* > [TF] I was specially asked to do the name matching example because
it is
* > widely used today. I am sure others can submit other policy example
as
* > separate IDs.
* 
* I agree fully that the there is some good purpose of this kind of
* algorithm.
* I am just wondering whether the EXAMPLE specification is sufficiently
* well defined. Looks like may ask for three quarks with
* keyusage, extendedkeyusage and validation algorithm instead
* of asking for some more obvious atomic things.
* 
* If I am an ssl client or server, I simply don't care whether the
* actual certificate has whatever key usages or so, I just want a yes/no
* answer and maybe a path for logging. I just give the set of
* names and certs,
* 
* Do we need to distinguish email-protection certs for signing and
* encryption?
[TF] If you want to provide another example you can do so in another
draft.
*

---

From: Peter Sylvester <[email-masked]>
Date: Sat, 15 May 2004 19:16:37 +0200 (MEST)

> [TF] Nice ideal, but Administrators of all descriptions make security
As long as we continue with innovation prohibiting companies. :-) 

> the embedded SCVP response.

I tend to agree. depends somewhat on the definition of 'process', clients
also do not process OCSP responses or time stamps, do they?

---

From: "Trevor Freeman" <[email-masked]>
Date: Mon, 17 May 2004 09:09:02 -0700

Hi Denis,
Another round will no longer than this is taking. Rather than read items
out of context, it is better to read the full proposal.
Trevor

* -----Original Message-----
* From: Denis Pinkas [mailto:[email-masked]]
* Sent: Monday, May 17, 2004 12:53 AM
* To: Trevor Freeman
* Cc: [email-masked]
* Subject: Re: SCVP & validation policies
* 
* Trevor,
* 
* > Hi Denis,
* 
* > As I said previous an OID is one of the possible options, but there
is
* > no consensus to make this mandatory so SCVP will continue to support
* > both options.
* 
* Making the OID optional as requested by Wen-Cheng Wang, does not
* necessarilly mean "supporting both options".
* 
* > I also don't see consensus that it is mandatory that a
* > SCVP server will always map a request back to the OID.
* 
* Many opinions, except one, are supporting this however.
* 
* > I will be posting SCVP 15 shortly so you can review the latest
draft.
* 
* An extract of the proposal sent to the mailing list and targeted to
this
* problem would probably save another round.
* 
* Denis
* 
* > Trevor
* >
* > -----Original Message-----
* > From: Denis Pinkas [mailto:[email-masked]]
* > Sent: Thursday, May 13, 2004 12:54 AM
* > To: Trevor Freeman
* > Cc: Florian Oelmaier; [email-masked]
* > Subject: Re: SCVP & validation policies
* >
* > 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)
* >
* >
*