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

["Piyush Jain" <[e-mail]>]

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

Don't know how you concluded this from either mine or Peter's comments.

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

My interpretation was that revocationDate tells you a) but not b). For b)
you need invalidity date extension. Your assertion is that revocationDate
does not tell you the revocation time. I think it is incorrect.  Here is the
excerpt from 5280 section 5.1.2.6
  "Certificates revoked by the CA are uniquely identified by the certificate
serial number.  The date on which the revocation occurred is specified.  The
time for revocationDate MUST  be expressed as described in section 5.1.2.4."


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

OCSP explicitly states that good status implies that certificate was never
revoked and does not necessarily imply that cert was issued or valid. And
that response extension may be used to convey additional information
regarding the status such as positive statements about issuance and
validity.  The code points were not defined but the provision for including
those additional statuses is clearly stated - by defining response
extension, not by overloading the meaning of revoked. 

>And from that list, in order to interoperate with the installed base
"certificateHold, reject" appears to be the most sensible choice.
I fail to understand how this helps interoperability. And what "install
base" are you talking about - public CA deployments, enterprise OCSP
deployments or something else.

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

All the more reason to add sections in OCSP to clarify the meaning of
revcationTime and revocationReason in OCSP. Currently there is no text for
these fields in OCSP and people fallback to 5280 to figure out what it means
and how it should be set.