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

From: [email-masked] (Peter Gutmann)
Date: Fri, 17 Jan 2003 18:13:35 +1300

The following draft was recently posted: 

  http://www.ietf.org/internet-drafts/draft-gutmann-ocsp-rtcs-00.txt

The (rather lengthy :-) abstract describes it as follows:

When the OCSP protocol was defined, the design was based on full compatibility
with CRL-based mechanisms.  This requires the use of a complex means of
certificate identification that has resulted in interoperability problems
among implementations, a design unsuited for high-throughput, real-time
operation, the inability to provide an unambiguous certificate status response
(the only thing that a CRL can say with certainty is "revoked"), and an online
responder tied to an offline mechanism (some CAs issue CRLs only once or twice
a day, even though they have an online, real- time certificate store
available).  A more practical problem is that it makes it impossible to
implement an OCSP responder not based on CRLs, for example one that consults a
certificate database or in-memory hash table to determine the presence or
absence of a valid certificate.

Fortunately, the authors of the OCSP RFC foresaw this situation by allowing a
client to specify, and a responder to return, more than one type of response.
Just as the original OCSP responses were designed for completely CRL-
compatible operation, this document specifies a response type that is designed
for real-time status operation, providing a response not from a stored CRL
using CRL-only mechanisms but directly from a live certificate store or in-
memory hash table.  This allows the responder to provide extended information
not possible with CRLs, combined a high level of performance not possible with
the original OCSP design.

In abstract terms, the responder is providing an implementation of an
authenticated dictionary D that responds to membership queries from relying
parties.  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?".

When returning a response, the responder is merely indicating that the queried
certificate is currently present in its set of valid certificates.  It is
purely an authenticated dictionary service and does not verify the certificate
in any way.  Relying parties requiring external verification services should
use the PKIX standard mechanisms for this [RFC 3379] and not RTCS.
Specifically, RTCS does not provide, and should not be assumed to provide, any
of the functionality of DPD/DPV.  It is purely a mechanism for running a high-
performance OCSP responder directly from a CA certificate store/in-memory
table.

Peter.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 28 Jan 2003 17:23:55 -0500

Peter describes the function provided by the RTCS extensions to OCSP 
as an "authenticated dictionary" service for certs. Peter and I 
discussed his I-D prior to posting and the concern I expressed then 
is that X.500 (and PKIX) have no notion of such a service, per se. Of 
course authenticated directory access is a good thing, but the 
presence of absence of a cert in a directory is NOT an indication of 
its status, either valid or revoked, in the X.500 model.

The concern I raised in my e-mail exchanges with Peter is that by 
extending the OCSP semantics from that of a revocation status 
protocol (by allowing responses that go beyond revocation status to 
indicate the presence of a cert in a database), RTCS into the realm 
of a delegated cert validation protocol. RTCS tells the requester 
whether a cert exists in a database maintained by a CA or a designee, 
where the database contains only valid certs. This is not a 
revocation  status function; it is a more general cert status 
function.

It is fair to say that RTCS does not provide all of the facilities of 
a DPV server as PKIX has defined. However, RTCS does provide 
validation of individual certs (by virtue of indicating whether the 
cert in question is valid or not) and that is a subset of the DPV 
service.  A series of requests to servers implementing RTCS mimics a 
subset of what a a DPV server would provide, offering a new function 
not presently available from any other X.500 or PKIX protocol.

Thus my concern was that RTCS competes with our DPV work and should 
be considered relative to that ongoing activity.  It is up to the WG 
to decide whether PKIX should consider RTCS as a separate work item 
unrelated to our DPV work, consider it a competitor to that work, or 
ignore it. In the first case we can add it to our list of work items, 
essentially deciding that it is not in conflict with the DPV work. In 
the second case we would probably reject it as it does not implement 
many of the DPV requirements. In this case we would also be saying 
that it should not proceed as an independent RFC, as it conflicts 
with the DPV work item and we have vowed to not produce duplicate 
standards for this function. In the third case we could allow it to 
proceed as an independent work outside of PKIX, and it could become 
an RFC.

I'd like to initiate discussion on this issue of the right 
categorization of this document, prior to any discussion of how well 
the proposed mechanism performs the indicated function

Steve

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 29 Jan 2003 10:02:42 +0100

Steve,
I have not seen the posting of such a protocol.
Could you provide me with a link?

Please pardon me if the following is wacko due to lack of information!

The mechanism described, initially sounded like a very useful and
simple extension to OCSP,  making full justification to the term
"on-line". 

But while thinking a bit more, I don't see why you actually need new
semantics for describing the situation where a certificate is not in the
CA' s database.  Isn't this just one of the ways you can implement a CA?
There can hardly be a requirement that "useless" (revoked, expired, or
on_holded), certificates should be published.  Not even in X.500.

Further I do not understand how RTCS can be in conflict with DPV/DPD.
From your description it seems that RTCS does not indicate that a
certificate is "trusted", only that it is OK to use and rely on from the CA's
point of view.

DPV/DPD's primary competitors is IMHO rather status quo, custom code,
and XKMS.  All three are up and running :-)

Anders

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 29 Jan 2003 11:04:25 +0100

Steve,

> Peter describes the function provided by the RTCS extensions to OCSP as 
> an "authenticated dictionary" service for certs. Peter and I discussed 
> his I-D prior to posting and the concern I expressed then is that X.500 
> (and PKIX) have no notion of such a service, per se. Of course 
> authenticated directory access is a good thing, but the presence of 
> absence of a cert in a directory is NOT an indication of its status, 
> either valid or revoked, in the X.500 model.

I fully share this view.

> extending the OCSP semantics from that of a revocation status protocol 
> (by allowing responses that go beyond revocation status to indicate the 
> presence of a cert in a database), RTCS into the realm of a delegated 
> cert validation protocol. RTCS tells the requester whether a cert exists 
> in a database maintained by a CA or a designee, where the database 
> contains only valid certs. This is not a revocation  status function; it 
> is a more general cert status function.

> It is fair to say that RTCS does not provide all of the facilities of a 
> DPV server as PKIX has defined. However, RTCS does provide validation of 
> individual certs (by virtue of indicating whether the cert in question 
> is valid or not) and that is a subset of the DPV service.  

No, it is not a subset of a DPV service. It could be considered as an 
addition to the OCSP service by providing additional information.
But here is the important question:

If it can be known that the certificate has really been issued, what kind
of use will be done by a RP with that additional information ?

The topic has probably to do with the compromission of a CA key. RFC 3280 is 
pretty silent about the verification of a certification path in the past 
when a CA key has been compromised. But tackling the question could also 
result in a change in the current validation algorithm. Could we afford two 
different processing for certification path validation ? I do not think so.

> A series of 
> requests to servers implementing RTCS mimics a subset of what a a DPV 
> server would provide, offering a new function not presently available 
> from any other X.500 or PKIX protocol.
> 
> Thus my concern was that RTCS competes with our DPV work and should be 
> considered relative to that ongoing activity.  It is up to the WG to 
> decide whether PKIX should consider RTCS as a separate work item 
> many of the DPV requirements. In this case we would also be saying that 
> it should not proceed as an independent RFC, as it conflicts with the 
> DPV work item and we have vowed to not produce duplicate standards for 
> this function. In the third case we could allow it to proceed as an 
> independent work outside of PKIX, and it could become an RFC.
> 
> categorization of this document, prior to any discussion of how well the 
> proposed mechanism performs the indicated function

Besides the categorization (it would be an additional function to OCSP),
it is more important to understand both the motivations for getting that
additional information and the consequences (which may be both advantages
and disadvantages) in the algorithm for the validation of a certification 
path, before going any further.

In particular, would it still be possible to verify a certification path 
using CRLs only ?

Would a consequence to have two different processings for certification path 
validation ?

We may well have a Pandora box in front of us.
Epimetheus did opened the box.

Peter, are you Epimetheus or Prometheus ?

Denis

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 29 Jan 2003 16:55:46 +0100

Denis,

For those who like me have not seen the document in question
here it is:
http://www.ietf.org/internet-drafts/draft-gutmann-ocsp-rtcs-00.txt

It is hard to see any controversy in this very clean way of addressing
certificate status info.  The problem is rather YAP (Yet Another Protocol).

<snip>

>of use will be done by a RP with that additional information ?

OK=>Valid => Rely on it.   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.

>different processing for certification path validation ? I do not think so.

There is nothing of the kind mentioned in the draft.  RTCS is just a
simple status-function totally agnostic to any CA key compromises.
(unless there is something "between the lines" I didn't understand)

Are we reading the same document? :-)

Path-validation using RTCS would go to the same place as OCSP.

<snip>

>In particular, would it still be possible to verify a certification path 

From RFC3280: The paragraph

  "6.3  CRL Validation

      This section describes the steps necessary to determine if a
      certificate is revoked or on hold status when CRLs are the revocation
      mechanism used by the certificate issuer"

seems to indicate that there are no CRL requirements.

>Would a consequence to have two different processings for
>certification path validation ?

Didn't OCSP bring us that already?

<snip>

Anders

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 29 Jan 2003 18:28:56 +0100

Anders,

> OK=>Valid => Rely on it.   

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

In fact the data base is suppsoed to be cut into two pieces, one piece for 
valid certificates and another piece for revoked certificate. This is 
implementation details. We are doing protocols able to answer questions like 
is the certificate revoked or not ?

> The extended reply returing a "replacement

I concur.

> (unless there is something "between the lines" I didn't understand)

Well in the intro: there is the argument "Is x present in D?" but I could 
not find the equivalent in the ASN.1 (that I did not fully decrypted before).

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. :-(

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

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.

Denis

---

From: "Marc Poulaud" <[email-masked]>
Date: Wed, 29 Jan 2003 21:43:20 -0000

Denis,

Ok, it might seem like a daft question, but I'm compelled to ask...

How does being present help a RP (act differently)? Or what real world
business problem does this solve? 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).

Marc.
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Denis Pinkas
Sent: Wednesday, January 29, 2003 17:29
To: Anders Rundgren
Cc: Peter Gutmann; Stephen Kent; [email-masked]
Subject: Re: Real-time Certificate Status Facility for OCSP - (RTCS)

Anders,

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

In fact the data base is suppsoed to be cut into two pieces, one piece for
valid certificates and another piece for revoked certificate. This is
implementation details. We are doing protocols able to answer questions
like
is the certificate revoked or not ?

I concur.

Well in the intro: there is the argument "Is x present in D?" but I could
not find the equivalent in the ASN.1 (that I did not fully decrypted
before).

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

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.

Denis

---

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

Marc,

> business problem does this solve? 

Since I am not Epimetheus, I will keep close the Pandora box and
let Peter answer that question.

Denis

> Having a status of Good would seem
>>certificate status info.  The problem is rather YAP (Yet Another
> 
> Protocol).
> 
>><snip>
>>
>>>If it can be known that the certificate has really been issued, what
>>
> kind
> 
>>>The topic has probably to do with the compromission of a CA key. RFC
>>
> 3280 is
> 
>>>result in a change in the current validation algorithm. Could we afford
>>
> two
> 
>>>different processing for certification path validation ? I do not think
>>
> so.
> 
>>
>>      certificate is revoked or on hold status when CRLs are the
> 
> revocation
>