Hi Russ,
----------
From: Russ Housley[SMTP:housley@spyrus.com]
Sent: Thursday, November 09, 2000 5:11 PM
To: ietf-pkix@imc.org
Subject: OCSP-X vs SCVP
A few weeks ago, there was a brief discussion of OCSP-X vs SCVP. The only
consensus point was that we need to have one PKIX solution for
certification path validation, not two. However, we did not pick one of
these two alternatives. I think we need to pick one. We should not put
further efforts into two solutions.
I think we're all in agreement here (including the chairs). My understanding is that by the end of this year (perhaps at the San Diego PKIX meeting, or perhaps immediately afterward via straw poll on the list) the PKIX group will have chosen a single protocol into which to put its efforts.
There are at least three communities that need to be served by this
protocol: very lightweight clients, organizations that want centralized
control, and clients that do not parse ASN.1 but understand XML. I am not
sure that there is consensus about these user groups. If not, we need to
get to consensus ...
I don't know if there is consensus about these three groups either, but they sound reasonable to me.
If these are the user groups that we are trying to satisfy, then I think
that SCVP is the better answer.
Here is where your train of thought loses me.
- Is SCVP significantly lighter weight than OCSP with the validation extension? I think it may possibly be lighter, but it's not clear to me that there is a significant difference, so I see little distinction here on which to make a decision.
- Organizations that want centralized control -- and want to achieve this through the use of a central server that gives validation answers -- can equally use SCVP or OCSP/DPV. The central responder model is the basis of both protocols, so again I don't see a distinction here.
- The value of XML (versus ASN.1 DER) for delegated path validation or discovery can be debated long and hard, and probably will be :-) However, these are just alternate encodings for the information that travels over the wire between the requester and the responder. Either protocol can be encoded in either way (as illustrated by SCVP, which is encoded in both ASN.1 DER and XML in the spec.). OCSP and its extensions does not currently have an appendix saying how to encode the protocol in XML, but there is nothing preventing a competent XML devotee from spending an hour to write this up and give it to the editors for inclusion. So, the XML "argument" does not distinguish these protocols either.
Let the debate begin ...
Agreed. Let the debate begin, but let it be based on something that will allow us to come to a conclusion. To me, the real distinguishing feature between the two offerings is fairly straightforward: does it make sense for the PKIX Working Group to define a framework for the "responder model" within which various questions can be asked in a standardized manner? If so, then OCSP is the right answer. (It currently proposes three possible questions: what is the status? what is the validity with respect to a given purpose? and what is the path with respect to a given root? Other questions can be defined if and when needed.) If we don't want such a framework, then we should go the other route and define a brand new protocol for every new question that someone dreams up.
I personally see little value in the latter alternative, regardless of how much fun it is to create new protocols. It makes much more sense to support such related questions in a framework protocol, especially because there may be cases in which combinations of questions are of interest to the requester (e.g., "give me the status (or the validation) answer, but ALSO give me the path you found so I can keep it for my evidence/archive records").
I think the framework protocol for the responder model is the right approach for defining and posing a set of similar questions. I suspect that as time moves on and we see requirements for new questions (or nuances on existing questions), having such a framework will stand us in good stead. This is why I've come down on the OCSP side, even though I currently see nothing technically wrong with SCVP. If XML is important (and I know that it is perceived to be, for at least some environments), then I'm sure that someone can find a co-op somewhere who'll do an encoding for OCSP and its extensions faster than America can choose a new President... :-)
Carlisle.