Re: SCVP 16 comments deadline

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Trevor,

(text deleted)

> [TF] You are advocating making the default policy selection implicit by
> omitting the policy form the request, we have chosen to make it explicit
> be defining a OID to represent the default policy. Functionally they are
> the same.

RFC 3379 states:

   A validation policy is a set of rules against which the validation of
   the certificate is performed.

RFC 3379 states:

   If the DPV request does not specify a validation policy, the server
   response MUST indicate the validation policy that was used.

SCVP MUST be compliant with RFC 3379.

> If the client specifies a policy it is one supported by the server
> which may or may not have parameters.
> [TF] Agreed

> Some parameters may be built-in in the policy and cannot be changed
> while some others may be allowed to be changed by the client.
> [TF] Agreed

> * 
> *  > The default
> * > values are also used when processing requests which reference a
> * > validation policy other than the default one that does not contain
> the
> * > full set of parameters necessary for validation and the client has
> also
> * > omitted the missing values in the request.
> * 
> * This sentence is rather long and complicated. I read it three times
> and
> * could not understand the exception for the default policy. If the
> default
> * policy is addressed above, we can simplify the sentence and only
> mention:

> [TF] All models contain the concept of default and non-default policy.
> If you specify a non-default policy, any parameter defined in the policy
> cannot be overridden by the client. Any parameter not defined by policy
> may be supplied by the client or the client can defer to the server
> default. If you specify the default policy, every parameter can be
> overridden.

You do not provide arguments against my proposal. However I noticed that 
your explanations are incorrect. If the default policy is being used (no OID 
specified in the request) then no paramter for that policy can be 
communicated by the client.

If a validation poilcy is specified by the client, then :

(1) some parameters for that policy are built-in in the policy and cannot be 
modified by the client (there are no policy parameters for doing this in the 
request), or

(2) some parameters for that policy may be specified by the client (there 
are policy parameters for doing this in the request). If they are not 
filed-in by the client, then either default values are used by the server or 
an error is returned.

> * "The default values are also used when processing requests which
> * reference a  validation policy that does not contain the full set of 
> * parameters necessary for validation and the client has also omitted
> * the missing values in the request."

> * > Therefore a client can also
> * > simplify the request by omitting a parameter from a request if the
> * > default value published by the server is acceptable.

> * This last sentence is correct.

(text deleted)

> * There should be non such concept of a "non-default policy".
> * Suppress "non-default" in the sentence.
> [TF] since we have the concept of default policy - we by definition get
> the non-default policy.

See above the argumentation against this.

Denis

> * > Therefore if you use the non-default policy, the policy value take
> * > precedence over the request value and cannot be overridden by the
> * > request. For the default policy the client can override any value.
> * 
> * No. See above.
> * 
> * Denis