Re: [pkix] Proposed resolution to non-issued certificates - 2560bis

[[e-mail] (Martin Rex)]

Piyush Jain wrote:
>
> I think Peter's point is that most folks consider revocationTime in OCSP
> equivalent to revocationDate in CRL.
> 
> This interpretation is not ill-formed given that OCSP has no text describing
> what revocationTime means in OCSP context.

But somewhat ignorant of how X.509 defines the meaning of revocationDate.

  ITU-T Rec. X.509 (08/2005), page 34:

   8.5.1 Requirements

   The following requirements relate to CRLs:

   d) A CRL contains, for each revoked certificate, the date when the
      authority posted the revocation. Further information may be known
      as to when an actual or suspected key compromise occurred, and this
      information may be valuable to a certificate user. The revocation
      date is insufficient to solve some disputes because, assuming the
      worst, all signatures issued during the validity period of the
      certificate have to be considered invalid. However, it may be
      important for a user that a signed document be recognized as
      valid even though the key used to sign the message was compromised
      after the signature was produced. To assist in solving this problem,
      a CRL entry can include a second date which indicates when it was
      known or suspected that the private key was compromised.


X.509 is pretty clear that the "revocationDate" entry does *NOT* mean
when a certificate was revoked, but instead, that it means when a
revocation was first published for the cert serial.  And this refers
to "publication on CRL", because publishing a CRL is the X.509 method
to "publish a revocation".

revocationDate of a CRL does not give you either of the two interesting
times: (a) when a certificate was revoked and (b) since when a certificate
is supposed to be invalid.

For conveying the latter (b), an optional crlEntry extension was defined,
and it is explicitly defined to predate "revocationDate":

  ITU-T Rec. X.509 (08/2005), page 36:

   8.5.2.4 Invalidity date extension

   This CRL entry extension field indicates the date at which it is
   known or suspected that the private key was compromised or that
   the certificate should otherwise be considered invalid. This date
   may be earlier than the revocation date in the CRL entry, which is
   the date at which the authority processed the revocation.


But we're actually discussing a certificate status reported through
OCSP that is *NOT* based on a revocation on a CRL.  So CRL semantics
clearly do not apply.  Now since the OCSP responder will typically

  (a) not have access to the cert for which the status is requested,

  (b) not know for which point in time the client will perform
      the validity check when obtaining the OCSP response

  (c) not know whether the RP supports the InvalidityDate extension.

A sensible and safe approach to issue a OCSP status response, for a cert
for which no record of issue exists, that will cause the RP to reject
that cert with very high probability, is to fill revocationDate with
a value suffiently far in the past, like Jan 1st, 1970.



> 
> And if you go by this interpretation, according to 5280, revocationDate
> cannot precede thisUpdate of an earlier CRL if the revocation for the
> certificate is being reported the first time.

OCSP was designed to report on status _other_ than revocation,
but didn't define any codepoints to convey "reject this cert"
other than those defined for CRLs.  And from that list, in order
to interoperate with the installed base "certificateHold, reject"
appears to be the most sensible choice.

Look at the history of draft-ietf-pkix-ocsp:

Section 3/2 Protocol Overview

 01-05:
   The Online Certificate Status Protocol (OCSP) enables applications to
   determine the revocation state of an identified certificate.

 06-07:
   The Online Certificate Status Protocol (OCSP) enables applications to
   determine the state of an identified certificate. 

 rfc2560:
   The Online Certificate Status Protocol (OCSP) enables applications to
   determine the (revocation) state of an identified certificate.

OCSP is *NOT* limited to CRLs as information source.
But it is currently limited to CRL ReasonCodes to expressing
"reject this cert".


> 
> Not saying that OCSP has to follow these rules, but given that it is
> deviating from CRLs on the meaning of revocationTime and revocationReason, a
> separated section describing these fields should be added.


There is no such thing as a strict sequence of OCSP responses, so the
conventions that apply to the relation of revocationDate to thisUpdate
for a serial listed on a CRL do not apply to OCSP.  FWIW, they also
apply only to the very first CRL that this serial appears on, so in
general, this is a pretty irrelevant characteristic for code that
processes CRLs and OCSP responses.


-Martin