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

From: [email-masked] (Peter Gutmann)
Date: Fri, 31 Jan 2003 16:10:03 +1300

"Simon Tardell" <[email-masked]> writes:

>If there is no "unknown" (=I don't have a clue) answer, then the RTCS server
>always has to be the authoritative source of information. You can't have two
>of them to offer redundancy, because the other one has no way to indicate
>that it is not sure that it is up to date. With a ternary response
>good/bad/gotosomeoneelse, redundancy is trivial.

Uhh... redundant failover is a network-level issue, not something for the
cert-status protocol.  RTCS is no better or worse off than OCSP, if the server
is down you go to the backup, if not you use the primary.  There's no need for
an "unknown" response, you either get a yes/no from the server, or you can't
contact it and fall back to whatever alternative you're using (redundant
failover, DNS SRV (which has what I thought was rather nice built-in load-
balancing until someone else delivered a long rant about how it wasn't the
place for it), or whatever).  The one I prefer, because it's so easy to tie
into the existing infrastructure, is an HTTP 302 - you're talking HTTP anyway,
may as well use the facilities it provides.  I would hope that redundancy with
RTCS isn't impossible, because if it is the existing systems doing it would
suddenly vanish in a puff of nonreality :-).

Peter.

---

From: "Simon Tardell" <[email-masked]>
Date: Fri, 31 Jan 2003 10:25:54 +0100

It is definitively an application level issue. Since you can bundle
requests regarding certificates from wildely disparate CAs the responder
must be able to indicate it knows the answer authoritatively to some of
them but not all. Giving up on the whole bunch and going to the next
doesn't solve anything, since the situation might be just the reverse
there!

So, yes, redundancy is possible, but only as long as you are only
answering for one (physical) CA.

Simon 

Simon Tardell, cell +46 70 3198319, [email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Peter Gutmann
> Sent: den 31 januari 2003 04:10
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: Real-time Certificate Status Facility for OCSP - (RTCS)
> 
> 
> 
> >If there is no "unknown" (=I don't have a clue) answer, then 
> the RTCS 
> >server always has to be the authoritative source of information. You 
> >can't have two of them to offer redundancy, because the 
> other one has 
> >no way to indicate that it is not sure that it is up to date. With a 
> >ternary response good/bad/gotosomeoneelse, redundancy is trivial.
> 
> Uhh... redundant failover is a network-level issue, not 
> something for the cert-status protocol.  RTCS is no better or 
> worse off than OCSP, if the server is down you go to the 
> backup, if not you use the primary.  There's no need for an 
> "unknown" response, you either get a yes/no from the server, 
> or you can't contact it and fall back to whatever alternative 
> you're using (redundant failover, DNS SRV (which has what I 
> thought was rather nice built-in load- balancing until 
> someone else delivered a long rant about how it wasn't the 
> place for it), or whatever).  The one I prefer, because it's 
> so easy to tie into the existing infrastructure, is an HTTP 
> 302 - you're talking HTTP anyway, may as well use the 
> facilities it provides.  I would hope that redundancy with 
> RTCS isn't impossible, because if it is the existing systems 
> doing it would suddenly vanish in a puff of nonreality :-).
> 
> Peter.
> 
>