Subject: RE: Comments on the DPV-DPD req doc

From: "Yuriy Dzambasow" <[email-masked]>
Date: Fri, 1 Mar 2002 10:47:31 -0500

...snip...

[COMMENT 10]

1. Section 4 2nd paragraph

If a client is asking a server to validate a certificate at
a particular time, that means "was the certificate valid at that
time" (based on information available at that time or information
obtained later). I don't think we should allow it to mean multiple
things.

[Answer 10]

The question is what means the sentence: "Is the certificate valid
at a time T ? ".  Does it mean:

1) valid when compared to the revocation status information that is
   available at that time T (which may not be up to date) ? , or

2) valid for the time T, where the key was used ?

These two times are not always identical and thus the response is
dependant upon the meaning of that time which is left to the policy.
Yuriy> I agree w/ Ambarish.  Since the meaning of the response is dependent
upon policy, we should not try and define the types of responses here.

[COMMENT 11]

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

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

...snip...

[COMMENT 16]

7. Section 7.1 7th para onwards

I thought the group had recommended against the "cautionary
period". Are you planning to get rid of these paragraphs?

[Answer 16]

This section is related to your first comment. This is what makes the
difference between the time T1, where the key was used and the time T2 where
the revocation information is available. I would guess that the next IETF
meeting will be the right place to discuss this issue, ... in corridors
first.
Yuriy> It seemed pretty clear to me from the poll on the list that
cautionary periods should be removed from this document.  I recommend
removing all text related to cautionary periods.
...snip...

[COMMENT 18]

9. Section 9

Any need to talk about DSV in this document? You aren't really
saying much about it - why mention it?

[Answer 18]

When the text was saying more, some people have been asking to say less.
Since now the text is saying less, you are suggesting more text ? :-)

yuriy> The document abstract says, "This document specifies the requirements
for Delegated Path Validation (DPV) and Delegated Path Discovery (DPD). It
also specifies the requirements for DPV and DPD policy management."  Based
on this, any text regarding DSV should be removed.

...snip...

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 04 Mar 2002 08:27:46 -0500

Yuriy:

>[Denis Answer 11]

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

---

From: "Yuriy Dzambasow" <[email-masked]>
Date: Tue, 5 Mar 2002 09:27:37 -0500

> these inputs on a per-request basis?

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