RE: DPV Request Policy Inputs

["Yuriy Dzambasow" <[e-mail]>]

Russ:

>
> Yuriy:
>
> >2. Section 4 3rd paragraph
> >
> >The requirements document should not forbid specification
> >of the policy with a request. If the protocol writers find that
> >specifying the policy (or a subset of the policy) with the
> >request is too burdensome, let them make that decision. Allowing
> >a client to specify a frequently changing part of the policy
> >with every request wouldn't be a bad decision
> >
> >[Denis Answer 11]
> >
> >Validation policies are usually not defined by end-users but by
> >administrators. So why a separate protocol should be used, the
> policy is not
> >locally defined. Clients should not define policies. As we know, policy
> >parameters are quite complex.
> >Yuriy> But clients can specify which trusted roots to use and certain
> >constraints.  I believe it would be beneficial in some cases
> (where policy
> >is easily defined) for a client to specify these things as part of a DPV
> >request, and not have to make a separate PDP request (which is
> more suitable
> >for complex policies).
>
> When I think of policy elements, I think of the inputs to the
> certification
> path validation algorithm in Son-of-2459.  Do you think that the protocol
> needs to include OPTIONAL fields that allow the client to specify all of
> these inputs on a per-request basis?
>
> Russ
>

Yes; however, it probably makes sense to examine the set of inputs defined
in son of 2459.  From section 6.1.1 in draft-ietf-pkix-new-part1-12, the
defined inputs are (followed by my comments):

a) a perspective certification path of length n

I don't believe it makes sense for a client to define this in a request to a
server, as the client probably has no knowledge of certificate path length

b) the current date/time

Rather than the current date/time, allow the client to specify some
specified date/time

c) user-initial-policy-set

Allow the client to specify this to a server.  I know of many environments
where relying parties use policy OIDs to determine a grade/level of
certificate to control access to applications and resources.  The validation
server typically is not aware of these specific relying party policy
requirements, and therefore the relying party client must be able to specify
this to the validation server.

d) trust anchor information

Allow the client to specify this to a server, for obvious reasons.

e) initial-policy-mapping-inhibit

Do not allow a client to specify this to a server, as policy mapping is
typically controlled by higher authorities.

f) initial-explicit-policy

I do not personally see a need for a client to specify this to a server, but
there probably exists a need somewhere.

3) initial-any-policy-inhibit

I do not personally see a need for a client to specify this to a server, but
there probably exists a need somewhere.

To summarize, the date/time, user-initial-policy-set, and trust anchor
information would be useful OPTIONAL parameters to pass from a client to a
server in a DPV/DPD request.

Yuriy