Subject: Re: DVD & DVP requirements

From: Stephen Kent <[email-masked]>
Date: Tue, 6 Feb 2001 15:56:55 -0500

Denis,

>Steve,
>
>  > My spec requires that the server be able to be configured with these
>  > policies. That will ensure that we have a definition of a minimum
>  > parameter set well defined for all servers.
>
>There are two approaches to define a policy, either by passing all the
>parameters in the request using ASN.1 or by referencing a policy which has
>been defined using e.g. English text. It is much faster to say in English :
>the leaf certificate must have either this field present or that other field
>present with the value X or Y, rather than saying the same thing using
>ASN.1.

It took a while, but I think I see what you're trying to say here. 
Yes, one could describe the policy in a natural language and make it 
available to human users that way, and these users would then employ 
a reference to the policy in a message to the server. But, what I was 
getting at is a requirement for the server to have some (not 
specified) means by which all of the defined parameters for 
validation are configured, i.e., the way the mechanism behind the 
natural language is configured.  The two descriptions are 
complementary.

>  > If we allow for external references, then we have to define a 
>reference format
>
>For external references we do not NEED to define such a reference format,
>plain English is sufficient, unless you prefer plain French. :-)

No, I think it does not suffice. I'll make a concrete proposal: for 
each policy configured on a server, the server will identify the 
policy via an OID. To ensure that the policy is what the user had in 
mind, the natural language format description of the policy will be 
hashed, and that hash will be passed as part of the policy reference. 
yes, I know that we could just use the hash as the id here, but using 
OIDs provides a structure in which one can encode info about where 
the policy comes from, etc. even with this we have the need to 
specify the canonical format for the natural language policy 
representation.

>
>  > (do you already have one in mind?), select a protocol and format 
>for transport of the parameters, etc.
>
>I do have in mind such a format which has been defined ASN.1. It could be
>used for describing the format as a parameter.
>
>You could derive it from a subset of the Electronic Signature Policies
><draft-ietf-smime-espolicies-00.txt>
>
>Here is a copy of sections which could be useful to define some (not all !)
>conditions:

Great. This seems to be a good set of parameters and I'll use that in 
the revised spec. The one change I envision is not requiring the 
trustpoint cert to be self-signed.

><snip of ASN.1>

>
>  > So, while it may be OK to have external references,
>
>Fine. On that point we both agree.
>
>  > I really want to keep the local config requirement as a base, and
>
>I am confused with the term that you use :"local configuration requirement".
>If the parameters, passed at the time of the request, define the validation
>policy then there is no such local configuration.
>
>Do you have in mind a protocol where you could define with one call the
>validation policy and then in another call ask for the validation using a
>refrence to that policy ? If so, I agree.

No, I am not mandating the ability for remote configuration of 
policies. The choices I envision are to pass in all the parameters, 
or to refer to a registered policy, known to the server, that has the 
same parameter choices.

>
>In that case, I would understand what a local configuration is, and then
>both calls would look the same.
>
>The case where the validation policy is referenced would have one call,
>while the case where the validation policy is locally defined would have two
>calls.

see my explanation above.

>
>  > I think the addition of external references adds complexity.
>
>Validation policies passed as a parameter add complexity.

True.

>
>  > >  > but only to the extent that the policies make use of standard
>  > >  > cert attribute validation parameters.
>  > >
>  > >Validation policies may include more controls than specified in 
>RFC 2459bis.
>  > >If these validation policies are defined using external 
>references, then it
>  > >is easy to point to them and thus avoids to describe them at the interface
>  > >level.
>  >
>  > Yes, and that leads to potential ambiguities and potentially
>  > undefined server operation.
>
>Not exactly. See above.

If the policies are NOT locally configured at the server, then we 
need a way to map a policy ID into a locator for the policy, and we 
have even more opportunities for processing to fail. I can see the 
error message displayed for the user: "Validation failed: unable to 
acquire referenced policy. Policy server unavailable ..."

>
>  > >  > To do what you propose would
>  > >  > require adding support for private extensions at the server and
>  > >  > perhaps in client requests.  This could be done if the WG wants, but
>  > >  > it would be a supplement to the mandatory, 2459bis validation
>  > >  > criteria.
>  > >
>  > >Describing parameters additional to the traditional validation algorithm
>  > >described in RFC2459, is indeed not that easy. For simplicity, these
>  > >addtional parameters should be limited to indicate conditions on the leaf
>  > >certificates.
>  >
>  > I'm not comfortable with pushing the problem under the rug in this
>  > fashion. We all love the power of indirection, but the reason I
>  > called for server config of parameters was to ensure that we had a
>  > well-defined list and that a compliant server implementation could be
>  > managed based on that list, without reference to some vendor-specific
>  > mechanisms.
>
>There is nothing such as "endor-specific mechanisms", but more "specific
>validation policies".

Let's end the debate and just specify a set now.

>  > >As a summary:
>  > >
>  > >1) Using validation policy references allows a simple interface and hides
>  > >the details (and complexity) of the validation policy.
>  >
>  > Are you suggesting that we not have a facility for the client to pass
>  > in validation parameters, but only have references to policies, or
>  > are you proposing external references in addition to explicit
>  > parameters in the request? I'm not sure I want to hide details of the
>  > policy. I think references to a policy are attractive as a means of
>  > centralizing management.
>  >
>  > >2) Using an explicit validation policy by describing all the parameters at
>  > >the interface level is more complex and in any case will have some
>  > >limitations when compared to referenced validation policies. I agree with
>  > >Steve, that it would be a supplement to the mandatory 2459bis validation
>  > >criteria.
>  >
>  > Not sure I know how to parse this last sentence, although I think I
>  > sense an overall disparagement of support for explicit parameters,
>  > which I still think is necessary.
>
>Explicit validation policies passed as a parameter are more complex. Now
>this is not a reason of not supporting them.
>
>So I am advocating the support of both cases:
>
>a) explicit validation policies AND
>b) referenced validation policies,

My revised proposal will support both, although you may not like the 
policy ID format.

Steve