Subject: RE: Summary:open issues for draft-ietf-pkix-dpv-dpd-req-03.txt

From: Ambarish Malpani <[email-masked]>
Date: Mon, 08 Apr 2002 11:20:53 -0700

Hi Tim,
    Any idea when and how we can come to closure on these issues? As far as
I am
concerned, an executive decision on the open issued would be fine - can we
just
move ahead?
 
Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com/> 
Mountain View, CA 94043

-----Original Message-----
From: Tim Polk [mailto:[email-masked]]
Sent: Thursday, April 04, 2002 3:01 PM
To: [email-masked]
Subject: Summary:open issues for draft-ietf-pkix-dpv-dpd-req-03.txt

Folks,

I think the discussion is converging here, and thought a summary was in
order.

There are a number of issues that were raised on the list and have
demonstrated consensus on the list.  (I will not enumerate them.)  Proposed
text has been submitted to the list and I sense general satisfaction with
that text.

However, there are two open issues that must be resolved before we forward
the document to the Area Directors.

Open Issue #1

The first issue involves "DPV relay".  Peter Sylvester has stated a
requirement for DPV servers to relay requests to one another:

>
>There is a requirement, similar as for OCSP caches, 
>that server just relays a request to another. This had been 
>discussed several times, the differences had only been to 
>what degree the relaying should become visible; whether one 
>server can rewrite/resigns the answers of another etc. 
>Relaying via cache is an obvious feature in many OCSP implementation, 
>how do they protect itself against loops between two servers? 
>

I understand this issue remains open.

Open Issue #2

The second issue is conformance requirements for multiple paths in the DPD
service.  As I read it, the current draft requires support for multiple
paths at the server, but not the client.  The client may request a maximum
number of paths N; if the request does not specify N, it defaults to one.
The DPD server includes zero, one, or up to N paths in a response.  If the
number of paths is less than N, this indicates that the server could not
find as many paths as the client requested.

Since the DPD process is performed with respect to a policy, just as in DPV,
it has been suggested that a DPD server could be designed to always return a
single path.  If the specified policy matches the path validation process
performed at the client (e.g., same certificate policies and same trust
anchor) the client should be able to use that path.

However, this could result in an ambiguity.  How does the DPD client that
requested three paths tell the difference between the following answers:
        "I gave you one path because it is the only one that exists"
     and
        "I gave you one path 'cause that's the way I was designed"

In the case where the single path failed, a client may need to know the
difference!

Careful selection of conformance requirements and error condition statements
will be required to permit building single answer DPD servers.

Moving Forward

Here is my plan for moving forward...

I will start two threads for the remaining open issues.  I consider all
other issues regarding the DPD/DPV requirements to be resolved.

Once the last two issues are resolved, I will ask the editors to post an -04
draft incorporating the currently agreed changes and the resolution to the
two open issues.  The -04 draft will be forwarded to the ADs.

Hope this works for everyone.

Thanks,

Tim Polk