[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: SCVP 16 comments deadline
Denis,
* -----Original Message-----
* From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
* Sent: Friday, December 10, 2004 9:14 AM
* To: Trevor Freeman
* Cc: ietf-pkix@xxxxxxx
* Subject: Re: SCVP 16 comments deadline
*
* 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.
[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.
*
* 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.
*
* "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.
[TF] since we have the concept of default policy - we by definition get
the non-default policy.
*
* > 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?
* > * >
* > * >
* > * >
* >
*