Subject: RE: OCSP request

From: Simon Tardell <[email-masked]>
Date: Wed, 9 Aug 2000 16:01:11 +0200

> 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. 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"
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"?

The other is the unclear wording of unknown. "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". 

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.

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

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 09 Aug 2000 16:48:13 +0200

Simon,

> 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

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".

> How would you suggest to signal "this certificate is not revoked, but it has

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
> base protocol. 

> I want to push out any assertions about other properties than

Good. So we strongly agree on this.

> representing that kind of assertions.

Forget the "However, ..." and the rest of the text, since as
indicated above, we strongly agree.

Regards,

Denis

---

From: Juergen Brauckmann <[email-masked]>
Date: Wed, 09 Aug 2000 17:30:37 +0200

>means "not revoked", no less no more. Nothing about "issued" or "not

Well, chapter 2.2 says
   The "good" state indicates a positive response to the status 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...

If good never means "issued", than it should not say "At a minimum" and
"not necessarily". 

The text may be correct, but it is possible to misinterpret it.

>ask for what reasons it does not know.

It is not described in rfc2560 what the client should do if it receives
"unknown" (try later? try another responder? Tell the user that it got
"unknown"?). It is not described when or why a server might give "unknown".
"Don't ask" may be adequate for a client programm, but is definitely not
adequate for people developing an OCSP responder.

Regards,
   Juergen