Re: SCVP 16 comments deadline

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Trevor,

> Hi Peter,
>
> Ho they are combined is defined in section 1.3
>
> " The referenced (policy) value indicates either a partial or full set
> of parameters. The client can therefore omit these agreed parameters
> from the request, only passing any parameters which are not specified by
> the previously agreed policy.  Therefore in the simplest form, with
> validation polices which define every parameter necessary, a SCVP
> request need only contain the certificate to be validated, the
> validation policy and any run-time parameters for the request.
>
> SCVP server also publishes its default validation policy settings.  The
> default policy can be requested for validation 

Up to here this is fine.

> and the client can  override any default value in the request if required.

I do not agree here. The default policy is used when the client does not 
specify anything and thus there are no parameters for the default validation 
policy.

If the client specifies a policy it is one supported by the server which may 
or may not have parameters.

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.

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

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

> Further 3.1.5.1 also requires
> " If there are any conflicts between the non-default policy referenced
> in the request and any supplied parameter values in the request, then
> the server MUST return an error response."

There should be non such concept of a "non-default policy".
Suppress "non-default" in the sentence.

> 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

> If the policy and client both omit a parameter, then the server default
> value is used.
>
> Trevor
>
> * -----Original Message-----
> * From: Peter Sylvester [mailto:Peter.Sylvester@xxxxxxxxxx]
> * Sent: Thursday, December 09, 2004 3:49 AM
> * To: Peter.Sylvester@xxxxxxxxxx; Trevor Freeman
> * Cc: ietf-pkix@xxxxxxx
> * Subject: RE: SCVP 16 comments deadline
> * 
> * Either I was unclear in my question or you have totally misunderstood
> it,
> * or I don't understand what your are responding.
> * 
> * > Hi Peter,
> * > All parameter assonated with policy mapping are names the same. If
> you
> * > want guidance on their use in combination with the policy reference
> see
> * > section 1.3.
> * It is obviously not difficult to guess which names corresponds, that
> * is not the problem.
> * 
> * 
> * > SCVP only supports one policy per request therefore if you want to
> * > process different polices for different certificates - send
> different
> * > requests.
> * Where do I talk about different policies and different certificates,
> * are you confusing this with another message?
> * 
> * I am just asking how parameters from the client and the server are
> * combined in a request for one signed cert with one policy. And, to
> * be sure, I can also assume that a client sets all the input flags
> * or none, if you want.
> * 
> * The current syntax allows all kind of combinations of settings and
> * by the client and the server, it is not specified:
> * 
> * - how they are combined
> * - whether there this only a subset of useful meanings.
> * 
> * > Trevor
> * >
> * > * -----Original Message-----
> * > * From: Peter Sylvester [mailto:Peter.Sylvester@xxxxxxxxxx]
> * > * Sent: Tuesday, December 07, 2004 4:15 AM
> * > * To: Trevor Freeman
> * > * Cc: ietf-pkix@xxxxxxx
> * > * Subject: Re: SCVP 16 comments deadline
> * > *
> * > * There are several boolean values like
> * > *
> * > *   ValidationPolicy ::= SEQUENCE {
> * > *     ...
> * > *     inhibitPolicyMapping  [2] BOOLEAN OPTIONAL,
> * > *
> * > * and a policy definition.
> * > *
> * > *   ValidationPolValues ::=SEQUENCE  {
> * > *     ...
> * > *     inhibitPolMap            BOOLEAN,
> * > *
> * > *
> * > * - It would be nice to use the same field names.
> * > *
> * > * - I suggest BOOLEAN DEFAULT FALSE for the inhibitPolMap together
> * > *   with some apppropriate tagging, it doesn't make much sense to
> * > *   me to code useless values.
> * > *
> * > * Would it be possible to add some statement about the intended
> * > * meaning of the 6 possible combination:
> * > *
> * > *
> * > * inhibitPolMap = FALSE
> * > *
> * > * inhibitPolicyMapping absent  1
> * > *                      FALSE   2
> * > *                      TRUE    3
> * > *
> * > * inhibitPolMap = TRUE
> * > *
> * > * inhibitPolicyMapping absent  4
> * > *                      FALSE   5
> * > *                      TRUE    6
> * > *
> * > *
> * > * Does it mean that when the client value takes preceedence over the
> * > * server value?
> * > *
> * > * 1 = FALSE
> * > * 2 = FALSE
> * > * 3 = TRUE
> * > * 4 = TRUE
> * > * 5 = FALSE
> * > * 6 = TRUE
> * > *
> * > *
> * > * It had been said some time ago (as far as I remember) that these
> * > * inputs are not global ones but in principle for each of the
> * > * certs to be asked for. what was the conclusion why they stay
> global
> * > * for all certs?
> * >
> * >
> * >