Subject: Possible deficiency in the current OCSP Standard (RFC 2560)

From: "Nabil Ghadiali" <[email-masked]>
Date: Mon, 9 Jun 2003 13:13:47 -0400

Our view is that there is a possible deficiency in the standard (RFC 2560)
in that the “CertStatus” field for each certificate (contained in an OCSP
Response) does not provide an appropriate value to indicate that the
certificate status is temporarily unavailable.

We would recommend that the OCSP standard be updated to add another value as
a possible “CertStatus”, clearly indicating that the Responder knows about
this CA, but cannot respond at this moment. One could propose a
recommendation to update this standard with another explicit “CertStatus”
along with the "Good", "Revoked" and "Unknown", for example,
"temporarilyUnavailable”.

1. Background
-------------------
An OCSP request can contain status requests for more than one certificate.
Hence the OCSP response can also provide status for more than one
certificate. The OCSP Response has an overall status field named
"responseStatus" which indicates the overall result of the Response
received. The possible values for "responseStatus" are:
	- successful
	- malformedRequest
	- internalError
	- tryLater
	- sigRequired
	- unauthorized

The OCSP Response also has a field named "CertStatus" for each certificate
on which status is provided. The possible values for "CertStatus" are:
	- good
	- revoked
	- unknown

The "unknown" state indicates that the Responder doesn't know about the
certificate being requested - (RFC 2560). This could be because 1) the
Responder is not authorized to respond for that particular CA, or 2) the
Responder doesn't have the latest CRL to make a valid Response. Although
this sentence can be interpreted in any which way, both cases fit the
description as per RFC 2560.

In the event that the OCSP Responder is operational, but unable to return a
status for the requested certificate, the "tryLater" response can be used to
indicate that the service exists, but is temporarily unable to respond (RFC
2560) - this could be because the Responder doesn't have the latest CRL to
make a valid Response.

2. A Working Example with the Possible Options
------------------------------------------------------------------
Let us take an example of an OCSP request sent to a Responder requesting the
status on 3 certificates issued by 3 different CA's. The Responder has valid
CRLs for 2 of them, but the last CRL has passed its NextUpdate time. There
are two ways to handle this issue:

1) If the Responder responds with an overall  “responseStatus of "tryLater",
then the OCSP Client will try again and may get the proper response at a
later time. However, in this case, the first OCSP Response will not allow
the Client to receive the status of the 2 valid certificates. The client
will interpret the “tryLater" as applicable for all 3 certificates.

2) If the Responder responds with a “responseStatus” of "successful", and a
“CertStatus” of "good" for the 2 valid certificates and "unknown" for the
third certificate, this would allow the status of the first two certificates
to be received by the Client. However, in this case, the Client does not
know how to interpret the “unknown” value for the third certificate –whether
it is because 1) the CRL was temporarily unavailable to make a valid
response or 2) The Responder does not respond for that CA in the first
place.

Thus each option has its own strengths and weaknesses.

Regards,
Nabil

Nabil Ghadiali
Security Engineer
Electrosoft Services, Inc.
7918 Jones Branch Drive, Suite 600, McLean, VA 22102
Tel:- (703)-918-4905, Tel:- (703)-918-4906 (Direct), Fax:- (703)-918-4908
www.electrosoft-inc.com

---

From: "Ryan M. Hurst" <[email-masked]>
Date: Mon, 9 Jun 2003 14:41:39 -0700

Nabil - Here is my stance on that, I believe the problem is actually in
the responseStatus structure, I think there should be a notAuthoritative
response. 

You see 2560, indicates response pre-production is a reasonable thing;
in-fact I don't think it's possible to scale to internet volumes without
this concept. But for it to be practical one needs to be able to return
an un-signed response indicating that that responder is not
authoritative for the certificates being queried. 

This has some potential issues with scenarios where a single response
caries CertIds from multiple CAs and only one is "unknown" but
in-practice I don't know how realistic that scenario is in the most
common CA signed and CA delegated models since discovery happens via a
AIA. If this was something that needed to be supported (which I do not
think is the case) a responseStatus of notAuthoritative would be needed
for the cases when the responder could respond for none of the
referenced CertID's and a new CertStatus of notAuthoritative would also
be needed. I personally think this adds un-needed complexity given the
protocols usage but it could be done none the less.

The existing protocol implies that a responder that pre-produces
generate a signed basic responses for all unknown certificates which
negates the value of pre-production. As such responders that support
this today return a responseStatus of notAuthorized to save the signing
operation.

As for your specific query of how does a responder indicate
authoritatively he doesn't have the answer now but may in the future? I
think the existing unknown status is appropriate for that. In-fact in my
experience that is exactly how it's been interpreted by the
implementations I have seen.

As for tryAgainLater, this is (in my opinion) more for server issues
e.g. database rebuild, server re-start, etc.

Ryan M. Hurst
Program Manager
Windows Trusted Platform Infrastructure
Microsoft Corporation
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Nabil Ghadiali
Sent: Monday, June 09, 2003 10:14 AM
To: [email-masked]
Subject: Possible deficiency in the current OCSP Standard (RFC 2560)

Our view is that there is a possible deficiency in the standard (RFC
2560)
in that the "CertStatus" field for each certificate (contained in an
OCSP
Response) does not provide an appropriate value to indicate that the
certificate status is temporarily unavailable.

We would recommend that the OCSP standard be updated to add another
value as
a possible "CertStatus", clearly indicating that the Responder knows
about
this CA, but cannot respond at this moment. One could propose a
recommendation to update this standard with another explicit
"CertStatus"
along with the "Good", "Revoked" and "Unknown", for example,
"temporarilyUnavailable".

1. Background
-------------------
An OCSP request can contain status requests for more than one
certificate.

The OCSP Response also has a field named "CertStatus" for each
certificate
on which status is provided. The possible values for "CertStatus" are:
	- good
	- revoked
	- unknown

In the event that the OCSP Responder is operational, but unable to
return a
status for the requested certificate, the "tryLater" response can be
used to
indicate that the service exists, but is temporarily unable to respond
(RFC
2560) - this could be because the Responder doesn't have the latest CRL
to
make a valid Response.

2. A Working Example with the Possible Options
------------------------------------------------------------------
Let us take an example of an OCSP request sent to a Responder requesting
the
status on 3 certificates issued by 3 different CA's. The Responder has
valid
CRLs for 2 of them, but the last CRL has passed its NextUpdate time.
There
are two ways to handle this issue:

1) If the Responder responds with an overall  "responseStatus of
"tryLater",
then the OCSP Client will try again and may get the proper response at a
later time. However, in this case, the first OCSP Response will not
allow
the Client to receive the status of the 2 valid certificates. The client
will interpret the "tryLater" as applicable for all 3 certificates.

2) If the Responder responds with a "responseStatus" of "successful",
and a
"CertStatus" of "good" for the 2 valid certificates and "unknown" for
the
third certificate, this would allow the status of the first two
certificates
to be received by the Client. However, in this case, the Client does not
know how to interpret the "unknown" value for the third certificate
-whether
it is because 1) the CRL was temporarily unavailable to make a valid
response or 2) The Responder does not respond for that CA in the first
place.

Regards,
Nabil

Nabil Ghadiali
Security Engineer
Electrosoft Services, Inc.
7918 Jones Branch Drive, Suite 600, McLean, VA 22102
Tel:- (703)-918-4905, Tel:- (703)-918-4906 (Direct), Fax:-
(703)-918-4908
www.electrosoft-inc.com

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 12 Jun 2003 01:20:33 +1200

"Ryan M. Hurst" <[email-masked]> writes:

>Nabil - Here is my stance on that, I believe the problem is actually in the
>responseStatus structure, I think there should be a notAuthoritative
>response.

I had to look at exactly the same issue in RTCS, the solution to this is
pretty simple:

-- Snip --

3.2.2.3 Extended status non-authoritative response

This response type may appear when the response is non-authoritative.  This
situation may occur when the responder being queried obtains information by
chaining to another, authoritative responder (an origin server in HTTP
terminology) which is temporarily unavailable.  Authoritative responders MUST
NOT return the statusNonAuthoritative status.  Non-authoritative responders
may either indicate that no authoritative response is available by omitting
the NonAuthoritativeInfo, or provide a non-authoritative response (for example
from cached data) in NonAuthoritativeInfo:

  NonAuthCertStatus ::= CertStatus ( EXCEPT statusNonAuthoritative )

  NonAuthoritativeInfo ::= SEQUENCE {
    lastAuthTime     RelativeTime,
    status           RESPONSEINFO.&status({ NonAuthCertStatus }),
    statusInfo       RESPONSEINFO.&StatusInfo({ NonAuthCertStatus }{ @status })
    }

  lastAuthTime indicates the time at which the last authoritative response was
  obtained.

-- Snip --

In other words you just encapsulate a standard response inside a wrapper
indicating that it's non-authoritative (the response info is optional if no
info at all is available, not shown above).

The rationale is:

-- Snip --

Responders can be operated in one of two modes.  In the most common mode, the
responder is authoritative and returns responses directly from the certificate
store or a shapshot of the certificate store.  In the less common mode, the
responder acts as an access concentrator/transaction coordinator/proxy for
other responders.  The following discussion of non-authoritative responses and
responders borrows from DNS concepts and terminology, which faces a similar
situation when handling DNS queries.

When a responder is non-authoritative, it may not be able to return a response
to a query directly from the authoritative source, or for performance reasons
may return a cached response, just as with DNS and HTTP servers.  In this case
the responder can return the last authoritative response, along with an
indication as to how low ago the response was authoritative.  The relying
party can then make a decision, based on the age of the cached response and
the value of the data involved, to rely on the cached information or to wait
for a fresh, authoritative response to become available.

Note that the use of the term "authoritative" differs slightly from its use in
DNS.  In DNS, cacheing for load-distribution purposes is very common, and
mechanisms to handle it are built ito the DNS, whereas with RTCS it would only
be used when there isn't a requirement for a hard real-time response.
However, RTCS can return an authoritative response (via an access
concentrator/transaction coordinator/proxy) without the responder which is
being queried itself being authoritative.  In HTTP terminology, the source of
the authoritative response is an origin server, with caches acting as
intermediaries to improve performance.  In this case the response is regarded
as being authoritative, since it is being forwarded from an authoritative
source/origin server. Only a cached response is non-authoritative.  This
differs from DNS, where the authority of an answer and the authority of a DNS
server are synonymous.  Further discussion of this style of cacheing model may
be found in section 13 of [RFC2068].  This document is recommended reading for
anyone considering the use of response cacheing for RTCS performance
enhancement purposes.

-- Snip --

Peter.