Re: [pkix] New draft-ietf-pkix-rfc2560bis-06

[[e-mail] (Martin Rex)]

Simon Tardell wrote:
>
> I suggest that we use your current text plus that, if "revoked" is used
> to say "never issued/not in database", the revocationReason should be
> certificateHold and that revocationTime should be set to midnight Jan 1
> 1950 (or some other time before the rise of PKI).

I support the "revoked, ReasonCode=CertificateHold" for OCSP responders
that can not find proof/indication that the cert in question was properly
issued.

The CertificateHold reason code is vitally important, because otherwise
the CA would have to keep track of OCSP responses given out from the
CA's OCSP responder that declared a serial as "permanently revoked"
in order to ensure that the CA will never issue a cert with that serial
in the future.  Looks like an unnecessary and easily avoidable burden to me.


I don't like the particular date Jan 1, 1950, for safety, a date >= 1970
ought to be chosen (so that it does not get negative when converted
to time_t, which has potential to confuse some code).

And since the timestamp is a GeneralizedTime, the date ought to be
given in exactly that format, e.g.  "700101010101Z"


What also should be noted is that the optional OCSP SingleResponseExtension
"CrlID" must not be used when this "not issued" certificate was not
conveyed through a CRL--and there currently is no means to convey
proof-of-cert-existence through CRLs unless they're revoked, and in the
latter case there would be no "not issued" OCSP response to convey.


> 
> On the other hand, I think we should consider Denis' comment:
> 
> *Saying that the certificate has not been issued is not fully appropriate.*


I believe it is very inappropriate for the spec to make any assumptions
about why exactly the OCSP responder believes that a cert (serial) has not
ever been issued.  The reason can be manyfold.  Besides an accidental or
fraudulent deletion (attack), it may be something as simple as a
database software bug.

What we might want to say is that failures to access the database
of issued certs ought to result in an unknown rather than revoked
OCSP response.

The records of issuance, that the OCSP responder has access to,
need not contain the whole certificate.  The information may be
limited to serial numbers of issued certificates, and it SHOULD
include a hash of the cert (at least SHA-1, preferably SHA-256 as well).
In particular, the OCSP responder may not have access to the
validity of issued certs or any other certificate characteristics or
certificate attributes.


-Martin