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

From: [email-masked] (Peter Gutmann)
Date: Fri, 31 Jan 2003 00:11:04 +1300

Denis Pinkas <[email-masked]> writes:

>>Having a status of Good would seem enough for an RP to rely on; any other
>>case means the RP can't rely on it (not present (which is presumably
>>'unknown') or revoked).
>
>Since I am not Epimetheus, I will keep close the Pandora box and let Peter
>answer that question.

Uhh, I'm not sure what there is to answer, since Marc has summed it up nicely.
In authenticated-dictionary terms it's "Present/Not present".  In more
specific cert-status terms it's "Good/Not good", in financial-institution
terms it's "Accepted/Declined", etc etc.  The concept of "Unknown" (which is
required in OCSP because it can't provide an unambiguous response) doesn't
even feature here.

Peter.

---

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

Peter,

> In authenticated-dictionary terms it's "Present/Not present".

This does not mean anything. RFC 3280 does not say what "present"
would mean. So if you ever get that status, you have no way to use it
with section 6 (Certificate Path Validation) from RFC 3280.

Denis

> In more

---

From: "Marc Poulaud" <[email-masked]>
Date: Thu, 30 Jan 2003 13:47:03 -0000

Peter,

Confession time - I've only just started reading your I-D on RTCS, and I'm
going to send you some comments on it.

I'll re-phrase my question:

How does a RP treating unknown as 'I cannot rely on this certificate' not
work?

I agree that having more information might help inform the RP and the SC
resolve the issue from a practical point of view, but the ambiguity you
talk of does not seem to materially affect what the RP will do in this
event. I did always think OK was a bit wishy-washy, but it's the context
around these states (and perhaps the specific business/contractual rules)
that determine the action by the RP (I think this is the point Carlisle
was making (Carlisle: aps if not)).

I suspect that the richness and unambiguity has to be a sufficient level
to enable the business (and systems) to work. Is OCSP high enough? Does
RTCS allow things to be done better/faster/cheaper? I'll read-all-bout-it
in the I-D :-)

Peter - can you help me with a specific example of where having less
ambiguity (than unknown) better informs the RP to the point they might act
differently?

Respectively,

Marc.
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Peter Gutmann
Sent: Thursday, January 30, 2003 11:11
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: Real-time Certificate Status Facility for OCSP - (RTCS)

>Since I am not Epimetheus, I will keep close the Pandora box and let
Peter

Uhh, I'm not sure what there is to answer, since Marc has summed it up
nicely.
In authenticated-dictionary terms it's "Present/Not present".  In more
specific cert-status terms it's "Good/Not good", in financial-institution
terms it's "Accepted/Declined", etc etc.  The concept of "Unknown" (which
is
required in OCSP because it can't provide an unambiguous response) doesn't
even feature here.

Peter.

---

From: "Simon Tardell" <[email-masked]>
Date: Thu, 30 Jan 2003 23:03:12 +0100

> >>Having a status of Good would seem enough for an RP to rely on; any 
> >>other case means the RP can't rely on it (not present (which is 
> >>presumably
> >>'unknown') or revoked).
> >
> >Since I am not Epimetheus, I will keep close the Pandora box and let 
> >Peter answer that question.
> 
> Uhh, I'm not sure what there is to answer, since Marc has 
> summed it up nicely. In authenticated-dictionary terms it's 
> "Present/Not present".  In more specific cert-status terms 
> it's "Good/Not good", in financial-institution terms it's 
> "Accepted/Declined", etc etc.  The concept of "Unknown" 
> (which is required in OCSP because it can't provide an 
> unambiguous response) doesn't even feature here.

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.

Simon

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

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 30 Jan 2003 23:10:35 +0100

Simon,
I assume that the "I don't know" thing is for independent responders
that are not directly hooked to the CA.   That seems to be out of scope.
Redundancy may though be in scope as anything like HTTP 500 or
time-out should force the client to look for other options (if there
are such...)

Anders

----- Original Message ----- 
From: "Simon Tardell" <[email-masked]>
To: "'Peter Gutmann'" <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, January 30, 2003 23:03
Subject: RE: Real-time Certificate Status Facility for OCSP - (RTCS)

Simon