[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: DPD & DPV requirements - Recursion Issues

Carlin,

Steve,

I'm sorry that this isn't much of an analysis, but I think
that any such analysis should clearly separate the issues.
Here are three issues that I can think of:

1) One issue concerns the syntactic complexity of the protocol.
If the protocol permits a DPV/DPD response to include embedded
DPD/DPD responses from other servers, then the syntax will be a
bit more complex than it might be otherwise.

Right.

2) A second issue concerns transitive trust.  This is an issue
even if embedded responses aren't permitted in the protocol.
A DPV/DPD server could contact another server and repackage
the response that it receives.  This issue might be addressed
by providing hooks in the protocol to limit the extent of this
transitive trust.  On the other hand, the issue might be
addressed by DPV/DPD server practice statements. "This is what
I might do, trust me or not."  Or the issue might be addressed
by a combination of the two by using policy OIDs in the request
to indicate which practice statement the client is willing
to tolerate.

I disagree with part of this. If a DPV server makes use of other DPV servers, but returns results that don't indicate such use, then it is mostly outside the scope of the protocol, i.e., we could not tell from examining the response. It might be stated in a published policy, something I would expect for a public server, but not a corporate (intranet) server. (Also, this discussion applies just to DPV servers, I think; a DPD server returns paths and data for ultimate evaluation by the client, so transitive trust is not an issue.) It's only when the response to a client include a data structure in which some part of the response is itself syntactically identified as coming from another DPV server that I think the discussion is applicable.

We already assume that a DPV server is making use of various other servers, e.g., LDAP servers and OCSP servers. But an LDAP sever is not a trusted repository, and a response from an OCSP server is clearly marked as such and must be maintained in that fashion to be valid. So the transitive trust aspect of simple DPV operation is limited to the OCSP responders that it uses. If the DPV client is not PKI-aware, I would not expect it to be able to meaningfully influence transitive trust in this way, since such controls require an understanding of PKI issues. Only the most basic sort of controls, invoked symbolically, might make sense.

3) A third issue is whether the benefits of recursion outweigh the
difficulties presented by the first two issues.  The authors of
the SCVP and OCSP-DPV proposals, and the author of the proposed
DPV/DPD requirements (someone well known to you, Steve) all chose
to permit OCSP v1 responses to be embedded in the DPD responses,
despite issues 1 and 2.

As noted above, the DPV and DPD cases are very separate here, and only DPV is likely to be a legitimate focus of this discussion. Yes, OCSP responses are included, and that introduces the transitive trust issue, but unless OCSP allows for recursion itself, I think we have an inherent limit in this case, i.e., it's not recursive, just 1-level delegation. Also, if one has a flag to say whether any OCSP responses are considered legitimate, then this provides a level of control that is simple to understand and exactly matches the delegation.

Steve