Subject: RE: OCSP identifiers

From: Michael Myers <[email-masked]>
Date: Mon, 27 Nov 2000 13:33:31 -0800

Dave,

> On Monday, November 20, 2000 8:58 AM you said in part:
> 
> CRL-driven [OCSP] responders are a requirement in my
> environment, and OCSP products which cannot be fed
> by CRLs will not be purchased.

When I said that "OCSP isn't and should't be tied to CRLs", I was observing
that CRLs are one means for a CA to store the data needed by an OCSP
responder.  Alternatives exist; these include direct database lookup or an
LDAP-based query of a directory.  We must preserve that flexibility.  RFC
2560 enables use of CRLs in any variation.  There's neither intent nor
proposal to remove that support.

Mike

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 28 Nov 2000 11:36:38 +0100

Michael,

> proposal to remove that support.

1° I agree with your text. The implication is that any basic status
revocation response should be built using only information that is present
in "fresh" CRLs. This may be self-evident, but it is better to say it.

2° I am still awaiting a response from you on my previous E-mails. Since you
might not remember, here is now (for the third time), the questions that I
raised:

========================================================================

E-mail from November, 15:

Mike,

A few, but important comments on this E-mail sent last week.

> Russ, thanks for getting this debate kicked off.  After all the work various
> of us have put into this issue, I was beginning to think no one cared.
> 
> All, as to the debate:
> 
> Let's hear from everybody before we make a decision.
> ----------------------------------------------------
> Thanks to all who have read the IDs and provided comments (especially Denis
> Pinkas).  But since active WG members have taken time out of their busy
> schedules to improve the IDs, I think it only fair that final judgement be
> witheld until those contributions are folded into a revised version for our
> consideration in San Diego.  At that time it might be more appropriate to
> decide between the two.
> 
> It's DPV vs. SCVP
> -----------------
> OCSP-X has expired; DPV and DPD replace that initial work.  The requirement
> we're all most concerned about is delegated path validation (although
> delegated path discovery has it's use). So it really comes down to DPV+DPD
> vs. SCVP since OCSP is already RFC 2560.  DPV is little more than an OID and
> a corresponding semantic; it simply puts more meat behind 2560's notion of
> "good". 

I disagree with this last statement. Extensions allows to request new
services. The request for each every new service may fail or succeed. This
means that each extension will have to carry the result of the request for
the new service. This also means that the current status will only carry the
response to a *status revocation request*, but will not carry any additional
meaning. "Good" is not the appropriate term to be used: "not revoked" is the
right term and should be used instead, when we revised OCSP.

>  DPD is only a bit more along these same lines of design.
> 
> They're going to do it anyway.
> ------------------------------
> DPV and DPD are nothing more than proposed standard extensions to the
> already existing extension hooks in 2560.  Given the availablility of those
> hooks, there's nothing to stop any environment from doing precisely this, if
> only to establish a closed system-level solution.  Given that, it's better
> that we take responsible action to promote Internet interoperability via a
> standard means of doing so in the event that such closed environments may
> someday find it useful to interoperate.

The real advantage to add DPV and DPD to OCSP is to be able to support both
a revocation status request and DPV or DPV+DPD in a single request. It
should however be noticed that a response to a status revocation request is
not mandatory since the server may well return a "revocation status unknown"
response, but still respond to a DPD (Delegated Path Discovery) for the
certificate. 

========================================================================

E-mail from November, 16:

Michael,

My original text contains several arguments; many of them do have no direct
answer in your reply. Please, next time, use my original text to reply.
Nevertheless, see my responses embedded in you new text.

> Denis,
> 
> Thanks for your in-depth review and comments on OCSPv2, both here and in
> your off-list communications.  To my reading, you have four points:
> 
> Replace "good" with "not revoked"
> ---------------------------------
> The last call for comments on the I-D that led to RFC2560 occurred roughly
> two years ago.

This is not an argument. The mis-use of "good", you currently make, is now
there to prove that there is a problem. Once again here is the text I
posted, on which you have not responded:

Extensions allows to request new services. The request for each every new
service may fail or succeed. This means that each extension will have to
carry the result of the request for the new service. This also means that
the current status will only carry the response to a *status revocation
request*, but will not carry any additional meaning. "Good" is not the
appropriate term to be used: "not revoked" is the right term and should be
used instead, when we revised OCSP.

> Replace "unknown" with "revocation status unknown"
> --------------------------------------------------
> See above.

The same.
 
> It should not be manadatory to implement revocation status.
> -----------------------------------------------------------
> RFC2560 asserts that servers SHALL implement revocation status.  In other
> words, "shall be capable of" in order to ensure a minimum level of
> interoperability across the Internet.  It does not however require
> deployment or activation of this functionality.  Does this clarification
> satisfy your concern?

This is not what I said. Here is my original text: 

" The real advantage to add DPV and DPD to OCSP is to be able to support
both a revocation status request and DPV or DPV+DPD in a single request. 
It should however be noticed that a response to a status revocation request
is not mandatory since the server may well return a "revocation status 
unknown" response, but still respond to a DPD (Delegated Path Discovery) 
for the certificate." 

Besides the exact wording, I would guess that we agree in principle on that
point.

(some text about CertId deleted)

It maybe the right time to mention that I have never be pleased by using:

 issuerNameHash      OCTET STRING, -- Hash of Issuer's DN

instead of the issuer DN. 

The argument given at this time was the following: since the server has some
private agreements with a CA he is working for, it knows their names and
then can compute the hash of that name. If the service that is requested is
only a path discovery, then the argument does not stand anymore, since the
server may have access to a large number of certificates which are
identified by their name, not their hash. Adding "issuer" to the list of
optional parameters would thus make sense. 

Besides the ASN.1, explanations would need to be given to tell which
combinations of these parameters make sense. The problem is that for the
basic service (i.e. a simple revocation status request), some combination
may be fine, but not sufficient for additional services (supported through
extensions). So we would have to anticipate the needs for these extensions. 

In order to make sure we do not miss anything, a study should be done, at
least for the three services that we are attempting to support, to explain
and identify which combinations of these parameters are needed and thus make
sense. 

I hope these explanations help.

========================================================================

Regards,

Denis