Subject: Proposed edits to OCSPv2 -01

From: Michael Myers <[email-masked]>
Date: Mon, 4 Dec 2000 12:53:54 -0800

Denis, all:

Here's a bit of a longish note proposing some edits to
draft-ietf-pkix-ocspv2-01.txt that get us to -02 and last call.

In summary:

1. Change "good" to "not revoked"; add "valid", "invalid",
   "suspended" and "expired" states; add corresponding semantic
   and normative text.

2. Add unsupportedOption and unrecognizedIdentifer to error cases.

3. Add normative text regarding the use of CRLs.

In the case of the "good" vs. "not revoked" revision, the bits on the wire
don't change, nor is there any essential change in semantics.  In effect,
all that's changing is the abstract symbol.  The only hit might be to
environments that are using "good" to mean "valid" in the delegated path
validation sense.  I doubt anyone's doing that, but if you are and this
change hits you, please let us know.  Otherwise, all you're going to have is
some source that uses "good" as a compile-time symbol  while the new
standard says "not revoked" but once the compile is done the corresponding
ASN.1 value [0] doesn't change anyway so interoperability is preserved; nor
are there any fundamental semantic changes.  Also, the new values will go on
the end of the end of the CertStatus choice with tag numbers > [2] so
there's no hit there either for v1 environments.  Same for the new error
conditions, which are only v2-relevant.

One other thing.  Many environments use a sequence of "revoked" and "not
revoked" to achieve a suspension effect.  Those who do so should take care
to read and comment on the new text "2.8 Use of CRLs" located at the end of
this note, especially given the proposal for a unique "suspended" response
value.

With regards to all,

Mike

2.2  Response
-------------
CURRENT -01 TEXT
   OCSP responses can be of various types.  An OCSP response consists of
   a response type and the bytes of the actual response. There is one
   basic type of OCSP response that MUST be supported by all OCSP
   servers and clients. The rest of this section pertains only to this
   basic response type.

PROPOSED -02 TEXT
   OCSP responses can be of various types, corresponding to various
   services.  An OCSP response consists of a response type and the
   bytes of the actual response. This document defines one standard
   response syntax, BasicOCSPResponse, and one standard service,
   id-pkix-ocsp-basic (see Section 4.2.1).

   The BasicOCSPResponse syntax MAY be used for other OCSP services
   not defined in this document.  However, the id-pkix-ocsp-basic
   service identifier SHALL only be used to report on the revocation
   status of a certificate (i.e. "revocation service").

   OCSP servers SHALL be capable of supporting revocation service.
   Environments that deploy OCSP for services other than revocation
   service are NOT required to activate the revocation service feature
   of their OCSP servers.

CURRENT -01 TEXT
   A basic response message is composed of:

PROPOSED -02 TEXT
   The BasicOCSPResponse syntax is composed of:

CURRENT -01 TEXT
   This specification defines the following definitive response
   indicators for use in the certificate status value:

   -- good
   -- revoked
   -- unknown

   The "good" state indicates a positive response to the status inquiry.
   When used in in a basic response, this positive response value indicates
   that the responder has current revocation information from the CA tha
   issued the certificate and that the certificate is not revoked, but does
   not necessarily mean that the certificate was ever issued or that the
time
   at which the response was produced is within the certificate's validity
   interval. Other response types or response extensions may be used to
convey
   additional information on assertions made by the responder regarding the
   status of the certificate such as positive statement about issuance,
validity, etc.

   The "revoked" state indicates that the certificate has been revoked
   (either permanantly or temporarily (on hold)).

   The "unknown" state indicates that the responder doesn't know about
   the certificate being requested.

PROPOSED -02 TEXT
   This specification defines the following definitive status
   values for use in BasicOCSPResponse:

   -- not revoked
   -- revoked
   -- unknown
   -- valid
   -- invalid
   -- suspended
   -- expired

   The "not revoked" value SHALL be used to indicate that the responder
   has current revocation information from the CA that issued the
   certificate and that that information indicates that the certificate
   is not revoked. The "not revoked" value MAY be returned for a previously
   revoked certificate that has expired as defined below.

   The "revoked" value SHALL be used to indicate that the revocation
   information currently available to the responder identifies the
   certificate as in that state.  The "not revoked" value MAY be returned
   for a previously revoked certificate that has expired as defined below.
   The "revoked" value MAY be returned for a previously-revoked certificate
   whose notAfter validity field has expired as defined below.

   The "unknown" value SHALL be used to indicate that the responder does
   not recognize the certificate as being among those for which it is
   authoritative.  When used in conjunction with id-pkix-ocsp-basic,
   "unknown" SHALL be interpreted as revocation status unknown.

   The "valid" value SHALL be used to indicate that the certificate
   at a minimum satisifes the path validation logic defined in RFC 2459.
   Correspondingly, the "invalid" value SHALL be used to indicate that
   the certificate at a minimum fails to satisfy RFC 2459 path validation
   rules.  Environments with a need to use these values MAY define service
   identifiers(i.e. OIDS) that uniquely identify the full set of practices
   and policies undertaken to confirm a certificate's validity within their
   environment.  Such practices and policies MAY include an assessment of
   the certificate's suitability for a given purpose or function in excess
   of the required compliance to RFC2459 path validation rules.

   The "valid" and "invalid" values SHALL NOT be returned in a
   id-pkix-ocsp-basic response.

   The "suspended" value SHALL be used to indicate that the responder
   has current information from the CA named in the certificate indicating
   that the certificate is suspended but not yet permanently revoked.
   OCSP responders MAY use a well-ordered sequence of "revoked" and
   "not revoked" responses to achieve the same effect.  The "suspended"
   value MAY be returned for certificate that has expired as defined below.

   The "expired" value SHALL be used to indicate that the responder has
   confirmed on the basis of its (the responder's) time base that the
   notAfter value in the certificate's Validity field is less than the
   current time as indicated by the responder's time base. Requirements
   governing the reliability of a responder's time base is beyond the
   scope of this specification.

2.3  Exception Cases
--------------------
CURRENT -01 TEXT
   -- malformedRequest
   -- internalError
   -- tryLater
   -- sigRequired
   -- unauthorized
   -- noMoreData

PROPOSED -02 TEXT
   -- malformedRequest
   -- internalError
   -- tryLater
   -- sigRequired
   -- unauthorized
   -- noMoreData
   -- unsupportedOption
   -- unrecognizedIdentifier

   "unsupportedOption" indicates that the responder recognizes
   the syntax of the request but does not support or is not being
   operated to support one or more service options specified in
   the request.  If the request is v1, the responder SHALL return
   "malformedRequest" rather than "unsupportedOption".

   "unrecognizedIdentifier" indicates that the responder cannot
   identify the certificate using the certificate identifier supplied
   in the request.  If the request is v1, the responder SHALL return
   "malformedRequest" rather than "unrecognizedIdentifier".

CURRENT -01 TEXT
   A server produces the "malformedRequest" response if the request
   received does not conform to the OCSP syntax.
                                    ^^^^

PROPOSED -02 TEXT
   A server produces the "malformedRequest" response if the request
   received does not conform to the required syntax.
                                    ^^^^^^^^

2.5  Response Pre-production
CURRENT -01 TEXT
   The time at or before which newer information will be available
   is reflected in the nextUpdate field, while the time at which
   ^^^^^^^^^^^^
   the response was produced will appear in the producedAt field
                             ^^^^
   of the response.

PROPOSED -02 TEXT
   The time at or before which newer information will be available
   SHALL appear in the nextUpdate field, while the time at which
   ^^^^^^^^^^^^
   the response was produced SHALL appear in the producedAt field
                             ^^^^^
   of the response.

2.6  OCSP Signature Authority Delegation
----------------------------------------
CURRENT -01 TEXT
   A certificate's issuer explicitly delegates OCSP signing authority
                          ^^^^^^^^^^         ^

PROPOSED -02 TEXT
   A certificate's issuer MAY explicitly delegate OCSP signing authority
                          ^^^
  
2.8  Use of CRLs  (new section)
PROPOSED -02 TEXT

   An id-pkix-ocsp-basic response MAY be produced using a data source other
   than CRLs.  Environments providing both id-pkix-ocsp-basic service and
   CRL maintenance service SHOULD ensure that both are synchronized with
   respect to the values of "revoked" and "not revoked" for certificates
   that are simultaneously subject to both services.  Such environments
   MAY exclude from the corresponding CRL certificates for which the value
   of "suspended" would be returned in their id-pkix-ocsp-basic service.

   [Notes to reviewers of this new section.  The essential issues are these:

      1. OCSP does not now nor ever has *required* the use of CRLs although
         the practice is known to be useful in some environments.  This
         clearly needs to be better spelled out since it continues to come
up.

      2. Where CRLs *are* relevant, a degree of synchronicity is vital.  A
         situation where, for example, there exists a "not revoked" OCSP
         response in the presence of a CRL listing a certificate is clearly
         a bad thing (or a good thing if you're a lawyer representing a
         party seeking remedy.)

      3. Suspension is a PITA with CRLs but easy with OCSP.  Since OCSP
revocation
         service isn't intrinsically linked to CRLs, we need to ensure that
we
         avoid creating a situation where the only reason to implement
CRL-based
         suspension is to deliver "suspended" responses.  If that situation
were
         to obtain, it's a sure bet there'd be very few if any "suspended"
         responses being exchanged across the Internet.  We'd all be back to
         the revoked/not revoked hack.]

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 05 Dec 2000 17:28:37 +0100

Michael,

> draft-ietf-pkix-ocspv2-01.txt that get us to -02 and last call.

I do not think we are ready for last call. :-(

>    "suspended" and "expired" states; add corresponding semantic

I skimmed through your text and would need more time than I have now to
respond. The only point I can say at this time, is that the change from
"good to "not revoked" is fine, but than I do not agree to introduce more
than the two other states that are presently defined in v1. "suspended" =
"revoked", with a secondary status information saying that it is temporary.
Remember that from a CRL point of view, there are only two status: revoked,
not revoked. Suspended is a refinement of revoked. OCSP v1 makes the
assumption that anyway the requester will have to get the certificate, so it
is able to know by looking directly at the certificate whether it is
"expired". This status is not needed. Then what would be the difference
between "not revoked" and "valid" ? Instead of fixing the problem, it
becomes worse. :-(

The major problem we will need to discuss next week, at San Diego, is the
use of an EXTENSION. 

If I understand your view, the status reflects the combination of all
queries, while in my view, the current status reflects the status about the
revocation status query only, status related to additional queries passed in
the extensions, come back in the extensions.

Would you now *PLEASE* respond to the following question (already raised
four times):

" Extensions allows to request new services. The request for each every new
service may fail or succeed. This means that each extension will have to
carry the result of the request for the new service. This also means that
the current status will only carry the response to a *status revocation
request*, but will not carry any additional meaning. 

The real advantage to add DPV and DPD to OCSP is to be able to support
both a revocation status request and DPV or DPV+DPD in a single request. 
It should however be noticed that (...) the server may well return a 
"revocation status unknown" response, but still respond to a DPD 
(Delegated Path Discovery) for the certificate." 
 
Since PKIX starts on Tuesday afternoon, let us have a corridor discussion
before, e.g. on Monday.

Denis