Subject: Re: Initial comments on SCVP

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 02 Jul 1999 20:02:54 -0700

At 06:28 PM 7/2/1999 -0700, Michael Myers wrote:
>I've got to wonder though if we need yet another online protocol or if we'd
>be doing our job better by building on our prior work.

Wonder no more. You, as an author on OCSP, know that the spec talks only 
about status. In order to extend it to do what SCVP is proposing, you would 
have to completely rewrite all of the semantics in sections 2 and 3, you 
would have to create about a dozen extensions (that would be marked 
critical, of course), and so on. In other words, it would no longer be OCSP 
at all.

>OCSP was in its inception aimed at solving the more general certificate
>validation problem. At the request of several very large stakeholders who
>intended to rely on OCSP for Internet-based financial transactions, we chose
>to first deal with the revocation problem, recognizing that via
>extensibility we were architecting a more general certificate validation
>framework.

Unfortunately, that latter phrase didn't come true at all. OCSP is so 
constrained in the semantics that extending it into validation is 
impossible without rewriting the whole spec. I guess that's the downside of 
giving "very large stakeholders" so much say on the scope of the protocol.

>Let's build on that, especially since it was the original intent of OCSP to
>do so.  With the investment people are today making in extensible OCSP, that
>only makes sense.

I'm not sure what you mean by this. Are you saying that developers would 
have an easier time adding a raft of critical extensions to one ASN.1-based 
request-response protocol than they would simply writing a new one? 
Interpreting the extensions would be just as hard as interpreting the new 
protocol, one imagines.

>It would relatively straightforward to publish an extensions document. Doing
>so, we would have the advantage of incrementally building on a existing RFC
>specifically intended to be extended in this fashion, for specifically this
>need, rather that totally revinent what that RFC has already established.

I disagree here. The extensions document would have to say "ignore the 
semantics and restrictions of sections 2 and 3 of OCSP", which very 
narrowly target status. The ASN.1 might be possible, of course, but the 
semantics of the extensions would require a significant over-riding of 
OCSP's semantics.

Of course, if the WG doesn't mind this, please feel free to write an OCSP 
extensions document that covers the same semantics as SCVP. If it looks 
like a better fit, we could just drop SCVP.

...except, of course, you have ignored the non-ASN.1 clients.

>Otherwise, what's the advantage of replacing a protocol that has already
>been ratified by the working group and promoted to proposed standard status?
>Especially since the requirements being met by the proposed protocol are
>already met or are intended to be met by extensions to RFC2560?

If OCSP was supposed to be extended with extensions for things other than 
revocation, why were the semantics crafted so narrowly to exclude them?

>   I just
>don't see a compelling case being made for so radical a revision.

Hopefully, you do now.

--Paul Hoffman, Director
--Internet Mail Consortium