Subject: Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15

From: [email-masked] (Martin Rex)
Date: Wed, 3 Apr 2013 12:53:37 +0200 (CEST)

I'm still unsure whether I understand what you conceive as a problem.

The scenario involves an OCSP client that is caching OCSP responses
and an OCSP responder that has been updated to know about
the certificate serials of issued certificates.

When an OCSP client performing a certificate path validation and
has newly obtained an OCSP for a certificate under investigation
for which it also has a cached OCSP response, how does the OCSP
client decide which of the two (the newly obtained OCSP response
or the OCSP response already in the cache) is "newer" and
supersedes the other.

For comparing the "freshness" of two OCSP responses, one needs to
look at "thisUpdate" -- which is supposed to originate from an authoritative
singular source of information.  And the very same single source of
information needs to provide the "thisUpdate" value for *all* kinds of
signed status responses so that they can properly supersede each other:

  - signed "good"
  - signed "unknown"
  - signed "revoked" (final)
  - signed "revoked" (temporary, published/CRL-based certificateHold)
  - signed "revoked" (temporary, "not issued" certificateHold)

If there is any problem, then it is not about relating "good"
and the newly defined "not issued" temporary revocation, but
instead in relating "good" to CRL-based temporary revocations
-- because the difference between "good" and "not issued" status
is determined with exactly one authoritative information source.
And if that information source does not provide published revocation
status as well, then it _must_not_ provide thisUpdate either.

Peter Rybar wrote:
>
> The value of revocationTime is not changed when hold is finally
> changed to e.g. keyCompromise!

This particular instruction applies only to "published certificateHold",
i.e. a certificateHold status that was previously published on a CRL.

It has no meaning for the "not issued" use of CertificateHold in OCSP,
since none of the "not issued" revocation/certificateHold OCSP responses
created by OCSP responders are processed and published by the CA
certificate revocation bureaucracy.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Wed, 3 Apr 2013 16:09:52 +0200 (CEST)

> status as well, then it _must_not_ provide thisUpdate either.

Processing of permanent/finally revoked OCSP responses can be
simplified: for final/permanent OCSP responses, thisUpdate can be ignored,
final/permanent OCSP responses can not be superseded at all and do
effectively not expire.  (New) OCSP responses with a final/permanent
revocation status will supersede any previously cached OCSP responses
that is not a final/permanent revocation; no comparison of thisUpdate
necessary for final/permant revocation OCSP responses.

The situations where messing around with thisUpdate can break things
are the transitions "good" -> "temporary revocation (certificateHold)"
and "temporary revocation (certificateHold)" -> "good".
And properly dealing with CRL-based certificateHold and deltaCRL-based
removedFromCRL is more complicated than deciding whether a
"notRevoked" status should rather be "revoked/certificateHold" or "unknown"
(and the latter may depend on whether you have a general OCSP client
 or a "Denis' QES OCSP client").

-Martin