Subject: Re: OCSPv2, DPV and DPD issues summary (long)

From: Peter Sylvester <[email-masked]>
Date: Wed, 7 Feb 2001 12:47:22 +0100 (MET)

> 
> >5.  Should DPD response syntax enable recursion?     [Covey, 1/4/01]
> >     (OCSP framework already enables recusion)
> 
> For now I don't see the utility of supporting nested responses in 
> DPV, or DPD. For a DPD server, it should be able to extract any 
> certs, CRLs, or OCSP responses it receives and pass on the extracted 
> data. In fact, it may not want to pass one all the data it gets from 
> another DPD server, i.e., it may winnow it. In case of DPV, we 
> discussed the fact that the client trusts the DPV server it uses, and 
> trust is not transitive, so there does not appear to be a need for a 
> DPV response to convey another DPV response, although a DPV server 
> may log the responses and save them in case they turn out to be wrong 
> and the server operator needs to track down the source of the error. 
> If a DPV server makes use of a DPD server, or vice versa, I think the 
> arguments above apply. So, for now, I see no need to support nested 
> responses.

It seems that we are in a real disagreement here: The case that a
DPV server want to 'log' the responses obtained from another DPV or
OCSP, is important. It is important that the DPV server can note
somewhere 'This information is based on a DPV request made at ...',
and the easiest way to do so is to include the original response. 

> >6.  There exists a need for loop detection.          [Sylvester, 1/11/01]
> >     (proposed: amend OCSPv2 and DPV I-Ds)
> 
> This still seems like a good requirement, and I'm looking for a 
> proposal of how to do it.

A strawman proposal:

A requester may add its identity to a
request. A server that relays a request MUST add his identity*
to the request. A server SHOULD relay all requesters in relayed
requests. 

When a server detects its own id it SHOULD reject the request. 

A server MAY reject a request when it would be forwarded
to any of the identities already available. 

A server may reject a request that contains too many requester
ids. (defined by local configuration of the server). 

> >7.  Transitive trust and recursion                   [Covey, 1/10/01]
> >     (proposed: amend OCSPv2 and DPV I-Ds)
> 
> see recursion discussion and proposed resolution above.
>

---

From: "Carlin Covey" <[email-masked]>
Date: Wed, 7 Feb 2001 11:11:10 -0700

Peter,

Please see my comments below.

<snip>

A strawman proposal:

[Carlin]  I'd like to add just a bit of clarification.  In response
          to a request, a DPV or DPD server may initiate an OCSP request.
          This OCSP request would not need to include the requester's ID
          for the purposes of loop detection (but perhaps for billing),
          because the OCSP server will not relay a request to another
server.
          The requester would add its identity to any DPV or DPD requests
          (with respect to the same target certificate [see ** below]) that
          it relays to another server.

[Carlin]  It isn't terribly efficient, but I suppose that a DPV or DPD
          server might relay a request to itself to deal with another part
          of the certificate chain.  I guess the "SHOULD" doesn't
          disallow that.

[Carlin]  ** It is possible that a request may be relayed through another
          server back to the same server to deal with another part of the
          certificate chain.  Perhaps this should be allowed, at least in
          some circumstances.  (In the presence of cross certification,
          there may exist certificate chain loops that do not pass through
          any of the requester's trust anchors.  The mechanism for dealing
          with this should be independent of the mechanism for dealing with
          certificate status request loops.)

---

From: Stephen Kent <[email-masked]>
Date: Thu, 8 Feb 2001 14:17:28 -0500

Peter,

>and the easiest way to do so is to include the original response.

There is some confusion here. We are in agreement that it would be 
good if each server along a path logged the response from the server 
from which it received a response. That does not require nested 
responses. Nested responses would be needed if we insisted that a 
client needed to be able to assemble this data, rather than relying 
on the DPV server(s) to maintain this data.

>ids. (defined by local configuration of the server).

OK. A list of IDs of servers that have been involved in processing a 
request seems reasonable. I'm not sure whether the situations Carlin 
notes in his response are ones we need to address, yet.

Steve

---

From: "Carlin Covey" <[email-masked]>
Date: Fri, 9 Feb 2001 10:13:24 -0700

<snip>

<snip>

Steve  

[Carlin]  I don't see a reason at this point to address the 
          "intentional loop" situations that I pointed out
          earlier.  I simply wanted to mention them in case
          someone wiser than I could foresee a problem.
          I'd be happy with a conscious decision not to 
          address these issues.

Regards,

Carlin

-----------------------------------

- Carlin Covey
  Cylink Corp.