Subject: Re: [pkix] Possible OCSP Extensions

From: Stephen Kent <[email-masked]>
Date: Mon, 19 Mar 2012 12:03:37 -0400

At 8:55 AM -0400 3/16/12, Phillip Hallam-Baker wrote:
>On Wed, Mar 14, 2012 at 4:47 PM, Stephen Kent <[email-masked]> wrote:
>>  At 2:13 PM -0400 3/14/12, Phillip Hallam-Baker wrote:
>>
>>  Does anyone use SCVP?
>>
>>
>>  I'll let others, who know better than I, respond to this question.
>>
>>  If there is going to be a choice between maintaining OCSP and
>>  maintaining SCVP then OCSP is going to be the one that I choose.
>>
>>
>>  If the proposal is to keep the name OCSP and add a lot of functionality
>>  that overlaps SCVP, that is not a reasonable course of action.
>
>OCSP is the Online Certificate Status Protocol. This is Certificate
>Status. So if we accept your argument that there is overlap with SCVP,
>the fault is with SCVP.

Not true. OCSP is a sloppy shorthand name or a protocol that reports the
revocation status of a cert, as noted in RFC 2560:

2.  Protocol Overview

    In lieu of or as a supplement to checking against a periodic CRL, it
    may be necessary to obtain timely information regarding the
    revocation status of a certificate (cf. [RFC2459], Section 3.3).

>This is a minor incremental development of the protocol to address a
>functionality that was originally intended.
>
>
>>  I didn't suggest abandoning OCSP in favor of SCVP. OCSP provides an
>>  alternative (to CRLs) for checking the revocation status of a cert. If we
>>  have good reasons
>>  to improve on that function, then doing so using OCSP makes sense.
>
>You suggested that the existence of SCVP means we cannot add new
>features to OCSP.

I suggested that if a new OCSP feature is already present in SCVP, then
we ought not add that feature to OCSP. That statement should be interpreted
by the context in which each protocol is intended to operate. So, if the
(not well articulated) problem space being addressed is public CAs, vs.
enterprise CAs, then SCVP is not an appropriate alternative.

>I said that I don't accept that as virtually nobody uses SCVP. So if
>you want to push that idea I think it is time to move SCVP to HISTORIC
>and slim down the stack a little.

I'll interpret this statement as a rhetorical gimmick on your part, 
as it does not merit being treated as a serious proposal.

>...
>
>The functionality is certificate status and SCVP is totally
>irrelevant. SCVP does not address this subject area and no public CA
>uses it.

I agree that SCVP is not an appropriate protocol for public CA cert 
status checking. But, since you've not provided a good description of 
the problem
that you want to solve with a change to OCSP, you didn't rule out SCVP.
Subsequent list traffic shows that some folks are interpreting your 
proposal in an enterprise context, which is where there is a direct 
conflict with an
extant PKIX standard.

>OCSP has an extension mechanism. It should have been used to implement
>SCVP in the first place.

You are entitled to that belief, but the WG did not agree. We went through
a long, fair process to decide how to proceed, and SCVP was the 
winner.  The fact that your pick didn't win then is not a basis for 
trying to reclassify
SCVP as historic.

In subsequent messages directed to other folks you said that a goal 
is "... enable a re-engineering of CA architecture so that we 
eliminate 'single break' systems."  That's a noble goal, but if it is 
also a big topic, not one that we address with a change to OCSP. 
Agsin, we lack an adequate description of the problem to be solved.

Steve