[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: OCSP identifiers
Mike,
As mentioned below, once more time, you do not provide any TECHNICAL answer.
I am still awaiting TECHNICAL answers to my questions.
> Denis,
>
> I will try again with responses embedded below for full context.
> Mike
>
> > Michael,
> >
> > I pick up this message to tell you that:
> >
> > > 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.
> >
> > 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.
>
> First you say, "I agree with your text" (which asserts that CRLs aren't
> required but rather their use is enabled), then you say that basic response
> should be built using ONLY [my emphasis] information present in fresh CRLs.
> These statements cancel each other out as far as I'm able to parse them.
> Please clarify.
Rather easy. OCSP server may use any information they wish (e.g. a private
access to a database of the non revoked certificates from the CA (if this
exists) or CRLs). Howveer, since the requester wants the same kind of
response whatever source of information is being used, only the common
denominator of that information should be used to produce the response. In
particular there should be no assumption that the OCSP server, * for a
revocation status query *, has access to more information than the one
contained in a CRL.
For other types of queries (i.e. other than revocation status queries), this
does not apply.
> > 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:
>
> I'll try again below with full context included.
>
> >
> > ==============================================================
> > ==========
> >
> > 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".
> >
>
> Denis said:
>
> > 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.
> >
>
> Response:
>
> On 11/17 under the subject "Re: DPV vs. SCVP", in response to your proposal
> to change "good" back to "not revoked" I responded in part as follows:
>
> "It's my sense that once the IETF makes a decision that leads to an RFC, we
> should be very cautious in recanting on those recommendations . . . . It's
> my opinion that we must think through a reset of the "good" and "unknown"
> status responses very carefully . . . . I look to the chairs for guidance
> to help me ensure that the IETF process is fully respected as we go forward
> . . . ."
I DID see this previous response from you. I present TECHNICAL arguments and
you reply, one more time, using PROCEDURAL arguments. I consider that this
is, once again, a non-response from you. I am still awaiting a TECHNICAL
answer to this question.
> If your definition of "response" means "the I-D hasn't been changed as I
> asked." that much is true for the reasons I cited above. However, and as
> I've said repeatedly, I remain open to strong consensus from the WG on your
> proposal or equivalently direction from the chairs.
>
> While I haven't conferred with my co-authors on this point, it would be
> useful to know if you would find acceptable an expansion of the CertStatus
> field of BasicOCSPResponse to include "not revoked" among the current
> "good", "revoked" and "unknown", with corresponding amendments to the
> related semantic text.
>
> > > 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.
> >
>
> Denis said:
>
> > 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.
> >
> >
>
> Response:
>
> Again, on 11/17 under the subject "Re: DPV vs. SCVP", I responded in part as
> follows:
>
> "I had hoped that you considered my prior emails as responsive.
Your hopes failed. :-(
Once more time, you do not provide any TECHNICAL answer. I am still awaiting
a TECHNICAL answer to this question.
Regards,
Denis
> Some of
> your comments I didn't take to be actionable in the absence of a broader
> consensus. I'll take another look at them today to see if I missed
> something obvious."
>
> Would consider responsive my ad-hoc proposal above to consider expansion of
> the spectrum of CertStatus values in BasicOCSPResponse?