Subject: RE: OCSP request

From: Juergen Brauckmann <[email-masked]>
Date: Tue, 08 Aug 2000 17:18:54 +0200

Sorry for the late reply... .

At 07:44 27.07.00 -0700, Ambarish Malpani wrote:
>Hi Juergen,
>    Originally, OCSP had the following states (I do this from
>memory, so I might be a little off):

Thank you.

>P.S. What is the status of the ISIS solution? Is it already a
>"rule/law"? Is it open to review/comments/suggestions?

ISIS is an interop specification by 9 German CAs (no, we currently don't
make laws;-).

I can send you a .pdf... .

Regards,
   Juergen

---

From: Ambarish Malpani <[email-masked]>
Date: Wed, 9 Aug 2000 08:31:28 -0700

I agree completely.

Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Wednesday, August 09, 2000 7:48 AM
> To: Simon Tardell
> Cc: [email-masked]
> Subject: Re: OCSP request
> 
> 
> Simon,
> 
> > > I do no think that any "clarification" is needed for RFC 2560 to
> > > this respect. The text is crystal clear and does not need to be
> > > changed.
> > 
> > With the risk or reiterating myself, I must insist that the 
> wording of
> > RFC2560 is not clear. 
> 
> With the risk of repeating myself, I must insist that the wording of
> RFC2560 is crystal clear.
> 
> > There are two problems. One is that the ternary
> > certificate status (good, revoked, unknown) is not 
> orthogonal, i.e. good is
> > not equivalent to !revoked. To dissect it:
> > 
> > 'The "good" state indicates a positive response to the 
> status inquiry.' --
> > so if the status inquiry was "is this certificate not 
> revoked and issued"
> 
> THIS IS NOT A CORRECT INQUIRY. The protocol overview says: "The
> Online Certificate Status Protocol (OCSP) enables applications to
> determine the (revocation) state of an identified certificate". Good
> means "not revoked", no less no more. Nothing about "issued" or "not
> issued".
> 
> > and the certificate was not revoked and not issued, "good" 
> would not be
> > correct. But clearly, "revoked" would not either. Note that 
> it does not say
> > "to the revocation inquiry".
> > 
> > 'At a minimum, this positive response indicates that the 
> certificate is not
> > revoked, but does not necessarily mean that the certificate 
> was ever issued
> > or that the time at which the response was produced is within the
> > certificate's validity interval.' -- yes, but the "minimum" 
> answer is only
> > reasonable if you don't ask (by request extensions or by 
> convention) for any
> > further assertions. To put it in other words, the responder 
> is required by
> > the protocol to make an assertion on the revocation status.
> > 
> > 'Response extensions may be used to convey additional information on
> > assertions made by the responder regarding the status of 
> the certificate
> > such as positive statement about issuance, validity, etc.' 
> -- what about
> > negative assertions on the same properties? Lack of the 
> same extension in
> > the response?
> > 
> > How would you suggest to signal "this certificate is not 
> revoked, but it has
> > never been issued"?
> 
> Very easy answer:
> The current status means "this certificate is not revoked".
> In an extension you can say whatever ADDITIONAL other information
> you want (including "issued, never issued").
> 
> > The other is the unclear wording of unknown. 
> 
> This is perfectly clear. If the server says "does not know", do not
> ask for what reasons it does not know.
> 
> > "doesn't know about the
> > certificate requested" is in ISIS an assertion that the 
> responder knows the
> > certificate was never issued. Clearly, there seems to be 
> differences in this
> > group about this. And the different interpretation of 
> "unknown" makes
> > difference for the behaviour of the OCSP client. If 
> "unknown" means that
> > some property of the certificate is bad (like in ISIS the issuance)
> > processing stops there. But if it means that this responder 
> is unable or
> > unwilling to answer your question about this specific 
> certificate (for
> > whatever reason) maybe you can try another responder, or 
> the same responder
> > later.
> > 
> > I am not primarily after defining any extensions for extra 
> assertions in the
> > base protocol. 
> 
> 
> > I want to push out any assertions about other properties than
> > revocation status from CertStatus into extensions. 
> CertStatus should, in my
> > mind, take one of "not revoked", "revoked" and "don't know".
> 
> Good. So we strongly agree on this.
> 
> > However, it does seem to me that many things you'd want to 
> ask an OCSP
> > responder have the same response structure as revocation 
> ("good", "bad",
> > "don't know"), so it could be beneficiary to define a 
> common type for
> > representing that kind of assertions.
> 
> Forget the "However, ..." and the rest of the text, since as
> indicated above, we strongly agree.
> 
> Regards,
> 
> Denis
> 
> > Simon.
> > 
> > Simon Tardell, Software Architect, iD2 Technologies
> > voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319
> > [email-masked], http://www.iD2tech.com
> > Securing the Internet economy
>