[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: SCVP 16 comments deadline



Hi Dan,
Thanks for the feedback. Answers below.
Thanks
Trevor

* -----Original Message-----
* From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
* On Behalf Of Dan Proietti
* Sent: Monday, December 06, 2004 11:08 AM
* To: ietf-pkix@xxxxxxx
* Subject: RE: SCVP 16 comments deadline
* 
* 
* Hi, Trevor.  I have a few comments re: default validation policy.
* 
* a) Section 1.3 states, "The default policy can be requested for
* validation and the client can override any default value in the
* request if required.  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." Section 6.14 is also quite clear about this.  However, in
* section 3.1.4, the field descriptions for the ValidationPolicy type
* imply that a fixed default is used when an OPTIONAL item is not
* included.  For instance the description for userPolicySet (section
* 3.1.5.3) states, "If userPolicySet is not specified, then any-policy
* MUST be used."  If section 1.3 still holds, the correct description
* should be something like, "If userPolicySet is not specified, then the
* value from the default validation policy will be used."  Same goes for
* the other ValidationPolicy field descriptions: inhibitPolicyMapping,
* requireExplicitPolicy, inhibitAnyPolicy, isCA, keyUsages,
* extendedKeyUsages.  If this is indeed the intent.

[TF] The conflict with default policy and user policy set has been
recognized and the requirement around any-policy in 3.1.5.3 has been
removed. Are there any other specifics in the section you reference
where you feel there is a conflict? I have reread those sections and
don't see any other clauses which appear to contradict the default
policy.

* 
* b) Section 3.1.5.1 is titled "Default Validation Algorithm" but
* discusses the default validation policy.

[TF] This should have read algorithm not policy and is now fixed.

  This is very confusing.  I
* presume this should be titled "Default Validation Policy" and be
* re-located to a sub-section of the validationPolRef description
* (3.1.4.1)?
* 
* c) Section 3.1.5.2.1 (Basic Validation Algorithm) defines the "meaning
* of the default validation algorithm".  This is extremely confusing as
* this is the first time this term is mentioned.  I presume "algorithm"
* should be changed to "policy" and the remainder of this sub-section
* should be merged into the "Default Validation Policy" section?

[TF] The basic validation algorithm is an algorithm not a policy in that
it defines how the parameters are compared not their values. 

* 
* d) Related to c) above, the second bullet states, "The acceptable
* policy set will come from the userPolicySet item.  If no certificate
* policies are specified in the userPolicySet item, then the SCVP server
* will use any-policy."  What if the server has defined the default

[TF] The clause in 3.1.5.3 around use of any-policy has been removed.


* validation policy with a userPolicySet of {1.2.3.4} and the client
* requests the default validation policy and does not specify a
* userPolicySet override?  Does the server use {1.2.3.4} or
* {any-policy}?  Or is it invalid for a server to define a default
* validation policy with a userPolicySet other than {any-policy}?
* 
* Personally, I think the specification needs to be more concise re:
* constructing the actual validation policy based on a) the referenced
* policy, b) the explicit overrides, and c) the default policy
fallbacks.
* An
* example with a hypothetical agreed upon validation policy would do it.

[TF] OK I will add an example of how this works to 17.

* 
* Thanks for your time,
* Dan Proietti
* 
* 
* 
* 
* On Thu, 2 Dec 2004 12:22:31 -0800, Trevor Freeman
* <trevorf@xxxxxxxxxxxxxxxxxxxxxx> wrote:
* >
* >
* >
* > The deadline communicated at the DC meeting for making comments on
SCVP
* 16
* > was Nov 30th which has now passed. I have had only three people send
me
* > comments to date. SCVP 17 will be closing very shortly so this is
the
* last
* > reminder.