Re: SCVP 16 comments deadline

[Dan Proietti <danproietti@xxxxxxxxx>]

Thanks for the reply, Trevor.  I've included additional clarification,
comments, and questions inline below.


Dan


On Tue, 7 Dec 2004 12:06:18 -0800, Trevor Freeman
<trevorf@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> 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.
> 

The clauses that are in error are:

3.1.5.4 inhibitPolicyMapping: "By default the server allows policy
mapping as part of certification path validation."

3.1.5.5 requireExplicitPolicy: "By default the server accepts no
policies in the certificate policies extension of valid certificates."

3.1.5.6 inhibitAnyPolicy: "By default the server processes the any-policy OID."

3.1.5.7 isCA: "If the BOOLEAN value is omitted from the request and
the client submits a CA certificate as the subject of the validation
request, then a server MUST NOT treat this as an error."

For each section I think that the quoted text should just be deleted. 
Default values for all these properties are defined by the validation
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.
> 

Huh?  What will this section be titled in 17?  "Default Validation
Algorithm" or "Default Validation Policy"?  My vote is for "Default
Validation Policy".

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

The issue that I intended to raise with b) and c) is with the term
"default validation algorithm".  What is the "default validation
algorithm"?  As I understand it, it is the validation algorithm that
must be used when requesting the "default validation policy".  And
this algorithm must be the "basic validation algorithm".  Is it indeed
necessary to include the specialized term "default validation
algorithm" when it is equivalent to the already established term
"basic validation algorithm"?

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

Fair enough.  If the fully resolved validation policy still does not
contain an explicit value for userPolicySet, the "basic validation
algorithm" dictates that {any-policy} will be used.  This is the
behavior defined in 3280 Section 6.

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

Much appreciated. 

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