Subject: Re: Real-time Certificate Status Facility for OCSP - (RTCS)

From: [email-masked] (Peter Gutmann)
Date: Thu, 30 Jan 2003 22:20:22 +1300

Denis Pinkas <[email-masked]> writes:

>The point mentionned in the draft is the following: A conventional OCSP
>responder answers the question "Is x excluded from D?", while an OCSP
>responder with RTCS capability answers the question "Is x present in D?".
>
>"Present in D" does not say "revoked" or "not revoked".

Right.  RTCS gives an unambiguous yes/no response, while OCSP gives a
maybe/maybe not response (a cert can be invalid without being revoked, and can
be valid but OCSP can't tell you that because it can only say "not revoked",
which doesn't mean "valid" - see the endless debate on this over the years).

>In fact the data base is suppsoed to be cut into two pieces, one piece for
>valid certificates and another piece for revoked certificate. 

Huh?  Why on earth would you want to do that?  Or are you talking about the
fact that this is what you have to do for OCSP?

>>The extended reply returing a "replacement certificate" is though hard to see
>>the point with.  Particularly as the likely scenario (which is?) is more
>>generally addressed by Peter's (!) other draft, the HTTP CertStore.
>
>I concur.

Users asked for it.  Since they're the real "consumers" of the RFC, I figured
it'd be a good idea to have that in there (I know that it's a radical concept
for PKIX to build something based on what users want, but I figured, what the
heck :-).  I'm open to suggestions though, if there's a strong justification
for doing one or the other it's no problem to change it.

>The RTCS extended response in fact prevents the use of CRLs only in the
>background since the certHash must be returned by the RTCS server. :-(

Why would it prevent that?

  memcpy( response.certHash, request.certHash, 20 );

>Furthermore, the basic response is incorrect since a BOOLEAN does not allow
>to answer "unknown" status anymore.

This is an artifact (bug, really) of OCSP.  I didn't think it was necessary to
make it fully bug-compatible.  This is sort of like complaining that Linux
doesn't have a BSOD like Windows does, and that this makes it inferior.

>The (only ?) "positive" idea of this contribution is to use a MAC to suppress
>the signature of every response, but there is no concrete proposal for it.

Oh, you seem to have missed section 2 of the draft.  You might want to re-read
it to see which problems it addresses.

(Denis, did you actually read the draft, or did you just come up with a list
 of assorted complaints and let fly?.  All of your complaints above, and more,
 are addressed in the draft).

Peter.

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 30 Jan 2003 14:07:21 +0100

Peter,

> maybe/maybe not response (a cert can be invalid without being revoked, 

"invalid without being revoked" does not mean anything.

> and can be valid but OCSP can't tell you that because it can only say "not revoked",

There is no such an endless debate, except from your side.

> fact that this is what you have to do for OCSP?

So what means "present" ? Present as a "revoked or a non revoked 
certificate" ? If this is the case, then your are "inventing" a new model 
where you would not need to sign certificates anymore. This would mean that 
if the TBS (to be signed certificate structure") is present in the database, 
then the certificate is "valid". Is it what you mean ? This can certainly be 
the matter on a new WG, but this is not the matter of the PKIX WG.

> Why would it prevent that?

Because the hash of a certificate is not included in the CRL, so using CRLs 
only would not be possible.

> This is an artifact (bug, really) of OCSP.  

This is not a bug in OCSP. OCSP can be used as a front-end where in the back 
office either CRLs or other OCSP responders may be used. So in case, the 
front-end cannot locate the right CRL or the right OCSP responder, the 
answer has to be "unknown".

> I didn't think it was necessary to make it fully bug-compatible.  

This is not a bug in OCSP. You should read again the document.

Denis

 > This is sort of like complaining that Linux